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ABSTRACT 

This thesis presents a model of a distributed system where the 
universe of objects in the distributed system is divided into mutually 
exclusive sets, dash set corresponding to a context. This model allows 
nagaine beyond the context boundaries, but Limits communications .across 
such boundaries to eceeeu passing only. Copying of complex data 
structures is investigated in this model, and semantics, algorithms, and 
sample implementations are prdseatedstor cates candidate Sag 
operations. Of particular interest is a new operation copy-full-local 
which copies a complex data structure to the boundaries of the context 


containing the object. 
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Chapter One 


Introduction 


Many aspects of computing are based on the ability to copy 
information. The foremost of these is parameter passing by value; in 
distributed systems, it is the only way to pass parameters between 
| program modules executing at different nodes. Since these parameters 
may be abstract objects whose actual representations are complex data 
structures, copying in this kind of environment is a non-trivial matter. 
The second area is a more general sharing where copies of some objects 
will be maintained at several nodes. Finally, copying is needed to move 
an object from one location to another; this is different from the 
previous, in that after an object is moved, there is still only one 
instance of the object in the system. Each of these and possibly other 
areas require the ability to copy objects. Each also ees other 
mechanisms, which have, in general, been topics of research. The 


research reported here has concentrated only on copying, in particular 


copying complex data structures.” 


In addition to the problems for which copying is a part of the 
solution, there are a number of interesting problems that must be 


addressed in developing semantics and algorithms for copying. For 


1. For example, if several copies of a mutable object exist in a 
system, a requirement may be that these copies be maintained in mutually 
consistent states. 


CT gen, memset ete 


example, consider .the situation “in ich .a structured object is being 


copted. Of interest -here :are those components ‘that are contained by 


flaming in more than one other “component, -in other words shared by other 


component objects. A decision must “be made :as to whether or not those 


‘shared components «are copied corily .enee, once “fer each. containing object, 


or once for each pointer to the object. Another question that must be 
answered is whether or not more: than ‘one . ‘kind. os a cory ‘operation is 
needed, and, if so, what the semantics | es the. aitferent r operations are, 
In order to address these prob lena, : va: midat is nenessary. This chapter 
will introduce the model of a distributed. —— used ee this research. 
Using the model, a discussion of - the problen. to. be aolved and an 
introduction to the solution will fallow. Research related to this work 


will then be EEA conkiadtse with ‘the plan | for: ‘the thesis. 


1.1 ‘Model of -a distributed :sysen 


The model of a distributed system used in | this research assumes the 
hardware of the system to be a network of ; computers, each computer 
having its own private memory or namespace for ‘objects. Since a bite 
namespace in a computer cnoy ides weithad enous tiexth iidity in eae ee 
objects nor enough protection in accessing -ebjects, this work first 
develops .-wedel .9f :aoentent that Gactlitaves:féeet: parkitioning:of-the 


namespace. 


Each computer or node in the distributed aye supports one or 
more contexts. The dnilvetes of ahiecke: ona nade form. disjoint sets, 


each set corresponding to a Single vetamege: Thus the context defines 


=O - 


FIGURES 


1.1. Contexts and communication by message passing ........ 
1.2. Communication within the distributed system .......... 
1.3. Sharing of components within a data structure ........ 
1.4. An example of the copy-full-local operation .......... 
3.1. A mutable CLU object of extended type ..........e-eee0- 
3.2. An example of an ObjeCt ....ccecccrccecccccceccresceres 
. The results of a copy-one .......... eT ee ee 
The results of a copy~full .... cc cccccccrcceccncvcene 
The results of a copy~full-local ......ccecccsccrccers 
Message-context and image for a copy-one .......ese00- 
Message-context and images for a copy-full ........... 
Message-context and images for copy-full-local ....... 
Receiving message-CcOntexts ...ccccccccccserececcccvace 
Layers in the system (on one node) .....c.cecccccvee ae 
Operations in the T type manager ......ccccccccccececs 
The generic copy operations .....cscvccccecceccceccces 
The send operation for message-contexts ....ceseeeeess 
Sharing across context boundaries .....ccceccecceenees 
Using copy-full-local for foreign components ......... 
Using copy-full for foreign components .........eece06 
The receive and receive~image operations .......eeeee. 
The generic receive operation ...cccccccnnccsccssceccs 
110. The receive-message~context operation .......ccccceee 
4.11. Modifications for local copying ...cccccceccrcccccees 


ee ee @€ @ e e@ . 8s @ 
eo ee @ @ 8 eo ee @ e ej .°8 e e 8 


COUNTRUE WHE ODUAULW 


RPE LEE EER WWW WWWw 
e 8 @ . e 


protection of groups of objects.where. a.group isa subset.of the set of 


all objects on -a:particubar«machine. 


= system model recognizes two: kinds Se catitias sitive and 
‘passive. The active entities ste Gallad-prooneses,<and can be sencueias 
in no more than one context at a time. ‘Since grocespesvare not of 
primary interest in this pessacthsiac further souinbtinds ate Jeni Bboue 
them. The passive entities are objects. “ALL-ob¥eets ‘have thie | 
attributes, value or state, name, and type. “Guery-object has a value | 
associated.with it. An object.will:have the value of cempty associated 
with it when it is created. oben tub iuedeve GE acs Se wes) dancoce KE 
permanence, .making the corresponding objects:matable. or immutable. An 
immutable object can be asaigned-a:value at most once, whereas a mutable 
object can be assigned a-walue more .than-omee. This is not meant. to 
imply that either :of these-necessarily ‘happens, ‘only that ‘the 
possibility exists. :At the level of contexts, every object will have at 
least one name, and will-have:exactly ane:in°its home :context. (As 
“mentioned previously, an object: may be:nameable from:.a ‘foreign: context, 
‘and in order to:do:.this: the foreign’ context must assign to the object.a 


fame that is local to the foreign context.) 


The third attribute of -an object ts :its sige: every object is of 
exactly one type for: its whole life. ‘By pe:48.-a sdeséeiption-«f those 
characteristics that a collection of .objects ‘have in common, a set of 
rules by which the objects -and-the weers-af ‘the objects: must abide. 
There exists a type manager.or some ‘other mechaniem for each type (there 


may be one instantiation of the type manager per object that may be 
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considered an integral part of the object, or there may be an overseer 
of a particular type) that. insures that only Eanratmoperattpas cee be 
performed on the objects being maintained by it. In this work, we a are 
assuming a single overseer oF type manager eO% all the objects of a type 
at a particular physical node. xcept for the més primitive types 
called base types, . which are provided by. the. aystem to each context, 
every type is defined “tn terms. of. other types; the representation of 
such a type is in terms of the representations of other types, and the 
operations provided by a type are defined in terms of operations on the 
component types... ‘The types that are not bape: types: are:koowa an 
extended t types. An extended type object contains a list of the Se of 
its component object. Such an object ‘contains nothing but names local - 


pery : “08D me a ge 


to the context in waich it resides. The definitions of extended types 


oo ste SS 
GE a 


form a network cf definitions that aust be mased a2 the final analysis 


¥ 


on the definitions of the base types. provided by the systen. 

Several supporting mechanisms for this model: of contexts are — 
necessary. These mechanisws form the keruel.: For the purposes. of this 
research, ‘only the message handler and: stotage. manager are of concern. 
Figure 1.2 depicts this situation. : The message handler must be able to | 
(1) pass messages between contexts local‘ to a single computer, (2) pass: 
-messages from a local context out into the’ network, and: (3) receive — 
messages and see that they are delivered to the correct local context... 
The message handler transforms messages passed between contexts into the 
kinds of messages that can be passed through the network hardware. The 


message handler contains information about low level protocols. It ig 
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Figure ? 1,2 A model of. the Commain tae din within and between nodes. of the 
distributed system. 


quite ppeatb is that the low level waceugas of the network do not 
correspond to the high tevst message objects or inages woich watt be 
discussed later in the thesia: These ae level messages may be 
buffered and sent in groupe, or split “thee énaller packets. Whatever is 
done by the message handler at such a low level is. hidden. from the 
contexts and users. The storage manager, 86 its. name. indicates, 
oversees storage of objects. For each object stored in the node, it 
provides a unique name in order that the phyaicel object may b eceheuad 
(through the storage manager). Each gtdtese name is known to a single 
context and associated with the local name assigned to that object by 


that context. 


1.2 The problem 


The problem that this thesis investigates is copying complex 
structures within the model that has been sketched. The complex 
structures in this case are objects of extended type, and the copying of 
particular interest here is copying across context boundaries. As was 
mentioned, copying is needed for a number of reasons. This research is 
a study of how to provide such copying: what the semantics of copying 
should be, and how to achieve them. In order to investigate copying 
further, we have set ourselves four goals: (1) any sharing that exists 
in the original structure must be maintained; (2) economy of mechanism 
by using a single approach in all copy operations defined (there will be 
three) is desirable; (3) since all communication between contexts is by 
message passing, the amount of message passing should be limited; (4) it 


should be possible to send and receive component images separately. 


Each of these is discussed below. 


The first goal to be discussed is the retention of sharing among 
components when copying an objects. Although a more common concern is 
sharing among processes or users, this research concentrates on sharing 
within an object. In the model assumed for this research, objects can 
have arbitrary structure, including recursive containment. The simplest 
question is whether maintenance of sharing would be necessary in copying 
objects if recursion were not allowed, but sharing components were, as 
in Figure 1.3(a). If sharing does not occur in a copy where it does in 
the original, the behavior of the copy may be different from the 


behavior of the original object under the same conditions. Now, 


ae ae 


(a) Non-recursive sharing . (b) Recursive sharing 


(c) Recursive sharing across context boundaries. 


Figure 1.3 Examples of sharing of components. within a data structure. 


es 


considering the more complex structure. that ‘Snebades recursive 
containment of components such as the structure in Figure 1.3(b), it 
becomes aven clearer that such sharing must be copied in order. to 
terminate a copy operation which. copies ‘the conpLetea ‘structure. Sharing 
across context boundaries, as in Figure’ 1.3(¢), adds a new dimension to. 
the problem of copying.» It does not introduce any-new reason for 
maintaining sharing, however, recursive structures dre much more 
difficult to detect across context boundaries. Thus, there is even a 


greater need for a mechanism that detects isuch sharing. 


Lappe tt 
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the local private memory or namespace. In eaeecea provide flexible 
control of sharing and to limit error propagation, the only means of 
commun teatton between contexts is by passing: messages... This censtraint 
allows enforcement of arbitrary degrees of provecr sos at the context 
boundaries. It does not eliminate the possibility of sharing an sbvert 
across context ‘houianties: but does Limit the means of access to that | 
obser; if an object is known beyond the boundary of its local context, 
the Gals means of operating on the object ie by passing the name ae such 
a foreign object ina message requesting that some edecacion ‘he | 
performed on the i ia in the containing | context. The user will see a 


collection of contexts with Sernneee flowing between then as in Figure 


1.1. 


Context B 
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Figure 1,1 Contexts containing objects and, communicating by. message. 
passing 


This model of a context piovides seoracriod at a level not 
generally provided in computer systems....It, is common for a system to 
enforce protection of the system as a whole; the requirement of 
passwords is pne such mechanism. At the-other extreme,’ individual 
objects are frequently protected; two common mechanisms. to achieve. this 
are capabilities and access control lists. -.Contexte allow for . 


eas ae 


| festa sori similar to Supyl aad copy are conrsane aad eopy 


a operation: the co 


-is an example of this. Gory those c 


- Figure 1. 4 An : Gedeste of the es 


level of the pete tose: copying pointers to al “the’ components of « ‘the | 


original. In fact, the copy: operation ie. defined: by cat Ling ‘sopyl on: a 


the original object, and then calling: cope for each component, woving 


through ‘the structure ipspeags ail the’ components avec baee copied. Sop 


pEovines the standard cement ies for copy by copying: alt of the: object, = 
and c eopyl 1 allows for ¢reation: of specially tatlored copying, in witch * 


“not all the components need to” be copied. In this research the: 


ou 


. The model of the system. presented in this paper. is ‘much more . 


complex. than. that of CLU, allowiag dace structures, to cross context 


boundaries.. AS a result, this research has Jed to a third kind of copy 


operation copies to 


the boundary of the context contataing the 2 origioal object. “Figure 1. A 


original = copy 


fuli-ioca’ operation. the etigece 
**, and the: 


Tabelled with * ie copied into alate Tabled 


component labelled 1 is copied into iv The componente labelled 2 and 3 
are not copied. oe ae. . 
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apo nts directly connected to the i 


top level (directly or through other local components) of the structure 


and in the original context are copied. This copy operation complements. 
the other two in such a way that the threé ‘provide ‘the user with a great 
deal of flexibility in copying complex data structures: across context. 


boundaries. 
1.3. Related work 


The model of a dtectibuted’ systen ‘ised in thts ‘césearct has been 
influenced strongly by the work of Saltzer[18], Liskov et ‘al. (10,11), 
and Svobodova et al.[19] In Saltzer’s work every object is associated’ 
with a context. or masiing environsient; al’ ‘the fidmes or pointers in an- 
object are » resolved with respect to cis context specified for that 
object. The purpose. oF contexts in Saltzer’ 8 } wOKK is to mentee what. he 
terms modular | sharing. A number of acess fron the ok: in cLU of Liskov 
et al.{10,11] have influenced this work. , First, the work on CLU . 
prescore a strong justification for abstractions or ; atrongly typed 
objects and type extension: Second, the cL eyntax ‘anid approach to 
modularity in programming has provided a baste for Anpleaentation of a 
number. of the most important procedures for this reseeret CLU also 
provides: approaches to fae pemanttcs of copying, ‘the copy and ¢ copy | 
operations for arrays and records, as ‘mentioned prevsquely: Both arrays 
and records can be complex etructures, The third ‘Strong influence on 
this research is the work on distributed ayeteme ve Svobodova et al. (19) 
The model of a distributed syeten in that work aegunes. 5 guardian dans 
communicating only by message passing. The usiverse a eaclcves in this 


. wodel is divided into two kinds of entities, active, which are called 


rae ts ee 


processes, and static, called ebjects. A guardian is composed of one or 
more. precesses and the local address space (the directly accessible | 
objects) of those processes. The local. address spaces of guardians are. 
mutually exclusive sets of objects. A scieaas or object can refer 
directly only to objects within the same stiacatens Across guardian 
boundaries only processes may be named directly; sbyecke-can be named 
indirectly by using tokens, external subs Gov Gbdigte, paseet to oly 
contexts by the context containing the object... The model used in this 
research is very similar to that of Svabodova et al., ‘except that this. 


work is concerned only with objects, nat, with, processes. 


It must be pointed out that a wariety of copying ‘algorithms have 
been satel sped oy other people. “Tese include “those ‘dtveloped simply as 
eping algort thes (for exeapis both Clark 13] and Fisher (31) and those 
with particular. fonctions in mind euch as garbage collection (for 
example McCarthy [12,13] and Baker[1]. Aithough these works must be 
Geaetaeted in a development of yet another copying algorithm, they 
present a common probles. They all use ‘the ‘copy. ‘that is being created 
as part of the workapare ceeded to generate the copy. lf copying ig to 
be performed across context boundaries, euch’ ‘use of ‘the copy implies. 
increaaud message passing. Because of the. cost dn time ‘and greater. 
possibility of failure due to the need for cooperation between contexts, 
‘for the purposes of this research an aitevastive apocaech wae chosen 


og 


that avoids these problems. 


The external marked database developed by Bishop[2) provides much 
of the mechanism in his copying garbage collection for areas that our 
message~contexts provide here. (Message-contexts will be discussed at 
length in Chapters 3 and 4.) In our case the sending message-context is 
the repository of the names of objects that have been copied (it also 
has other functions) and the receiving message-context holds the names 
of the new objects containing the copies of the various components, in 
copying from lis original object into an image and from an image into 
the copy in the receiving context. Bishop achieves this in one phase 


because he is not copying across naming boundaries. 


1.4 Plan for the thesis 


—— 


The remainder of this thesis can be divided into two parts. The 
first is a further amplification of the model of the distributed system: 
this is encompassed in Chapter 2. The second contains the discussion of 
the copy operations proposed as a solution to the problem of copying 


complex structures; Chapters 3 and 4 present this material. 


Chapter 2 discusses in greater detail the nature of contexts. 
Three complementary views of contexts are presented: (1) the context as 
a naming environment, (2) the context as a node in an abstract network, 
and (3) the context as an object. All three views are used throughout 


the rest of the thesis. 


Chapter 3 introduces the three copy operations. The mechanisms for 
the copy operations meeting the goals discussed earlier are presented in 


this chapter. This is then followed by a description of the algorithms 
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for sending and: receiving in: the contexts between which.:the copying. is 


betng : done. ‘ ‘ $ : Pol Reo ae 


Graptee 4 investigates in greater detail. two new. types of F ebsects, 
proposed in order to achieve che: dopeine: papauees’ in Chapter 3. It is 
then recognized that the sinplieat. approach to providing. copying for _ 
typed objects is. to provide. generic operations or procedures that can be 
invoked by individual type managers. "Possible: implementations of the 
important operations: are then presented, One. soaelusion to be drawn 
from this work. is that most of the machentean pends £54 copying can be 
provided by the systencte the individual contexts, an the formof, the 
generic operations, and that paeretore: including the. type specific copy 


operations in particular type managers ie not. very disticult. | 


Shepess 5 is the concluding chapter, of the theaie.. It summarizes 
the thesis, and then discusses poedinie dizections for further. research 


related to this: vark... ae ee te gee Wag 
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Chapter Two 


Contexts 


Contexts can be viewed as several different, but complementary, 
classes of entities. As they were first presented, they appear to the 
user to be namespaces. A context is an environment in which local 
objects exist and can name each other using only names local to the 
context in which they reside. An extension of this view leads to 
classifying contexts as nodes in an abstract network. The nodes can 
communicate only by sending messages. It is also possible to 
extrapolate from the brief discussion in Chapter 1 to the point where 
contexts are considered to be typed objects themselves. Their behavior 
should be strictly circumscribed; their structure and the operations 


defined on them must be carefully specified. 


This chapter will discuss separately these three aspects of 
contexts. It will conclude with a brief discussion of how contexts will 


be viewed throughout the remainder of the thesis. 
2.1 Naming environment 


Names are fundamental to referring to entities in a computer 
system. There are situations in which the value of an entity is used 
for identification, such as in an associative memory; however, this has 


not be shown to be practical when the value of the entity has a complex 
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structure. Thus, we will assume that each entity must have a name in 


addition to its value or state. 


A naming mechanism, if it ig designed: sad implemented properly, can 
provide flexibility in two. dixections, -modulardty.aed. sharing, as 
discussed by Saltzer({18). Tag achievenent. of modularity. in a naming. 
mechanism means that entities can be | naned (contained), by. other . entities. 
without concern for what names are. chosen within eack,. entity. In 
particular, if two objects 1. and. 2. uae. che sane ane. A to imply. 
different objects, ) and 4 respectively, then abject 1 should also be | 
. able to name object 2. wi thout caueing. a probes with the teference Ada. 
object 23. the reference A. in abject 1 whl adit. Andicate object 3, and 

the xefarence A in object 2 will etal indicate object: ae. ~ mentioned. 
in Chapter As. Saltzer’ 8 context ei} provide: thie. facility. “Our 


COpEeTES: are modelled after hie ia. thie respect, gst 


ce The other ‘Amportaat goal. of. a 1 naming mechamien ; Ag sharing. ‘Sharing 
implies that there ig more. isa: one seccurmence of: che. name. for an. object 
or that there is more than one aman, $0: the object. | javonen: ose 
there is more than‘oue: object naming the shared obsect. and. therefore. 


: ae 
having some taré of access to it. Since we Previous! 


deteruiiad that 
pbisete are identified hy nanas,, a avaral if ferent nanes are, used for 
a shared. object,: hey must. sa. the: fioal.analyete senalve. to. khe,cane. 

name. Thus at the time a. pefeneace io nade neiag w.perticular. name, the 
name must be resolvable. uniquely but, di$tecent. nec 


to provide this uniqueness of name resolution. At one end of the range, 


there is a mechanism such as the reference tree developed by 


oe a 


Halstead{6]. Reference trees provide a basis for relative naming. A 
reference tree for an object can be considered to be a connected acyclic 
graph. The nodes of such a graph represent those entities that know 
about the object in question. A given node knows for each object which 
of its immediate neighbors know about the object. Using such a graph, 
the object could have a different name for each arc in the graph as long 
as each end of each arc maintains the necessary information. It is not 
clear that this is a aera approach to take, but it is possible. At 
the other extreme, it is possible to have names that are unique for all 
time. An example of such a mechanism is a capability system[4] ; 
eapabilities are names that are unique for all time and ee coe 
Finally, it is sufficient to provide names that are all unique at any 
specific time, but are not unique for all time. The standard use of 


physical addresses is an example of this. At any one time no more than 


one object can have a specific address in memory, but the same address 


1. Some capability systems, have been proposed in which the object 
name within a capability is a virtual address and thus is not unique for 
all time. For example, Bishop uses this approach[2]. 
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can ke used by different opiects at different times. This last 


apptroach is sabuscd in our "models alt the leckts on a hone will be co 
given names that are unique at any given tlaes = The management “and 


tesolution of names will be provided by the kernel” of ‘the node. 


Within a node, even if the nede. is a. pexagnal computer; used by. 
only one person at a time, it way be.useful to, be.sble,to divide the 
world of objects into smaller worlds. ‘This may be: simply for. 


convenience, or there may be.more pressiag ceasons. for it such as. 


security or containment for wertticattons tyes, ia edgh fton to.the ... 


“2 
environments called contezts. | etsy sees lacie hae 


resolving ability for names known in the local enviroment into those ae 
names unique to the whole node. ‘The. whole of \a node.will.be divided. vee 


into contexts, such that every object will be in exactly one context. 


1, As a matter of fact, in the Multics systea, there are names of. all 
three degrees of uniqueness. A segment that is shared by two or more | 
processes, probably will be known by a. different segment number in the 
KST or Known Segment Table of each process; thus there will be different | 
names for the same segment. At a different level in naming the segment, 
when a page of it is in primary memory, if two processes want to access 
that page, their different names for the information they want 
(different because of the different segment. auebers) must resolve to the 
same physical address. On the other hand, if the segment is not used 
for a period of time it may be moved from primary memory, and the 
physical space used for something else; the physical addresa now may be 
an address of a page of a different segment. Finally, each segment has 
a unique name by which it can be recognized. These last names are 
capabilities; they are unique. for all time, and unforgeable. They are. 
part of the information about a er in an facade iw a KST.” iicaare a 


see Organick{15]. 


2. Since this work is to a : dares exteat. eres on “Saltzer’: 8 ; work < on 
naming[{18], the term "context" was adopted. 
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When an object is created, part of the creation operation is the 
assignment of a name local to the context in which the object is being 
created to that object. The context is the repository for the knowledge 
about whether or not a particular object exists within its domain. As 
long as the context knows the local name and the storage name that is 
associated with it, the object exists. Since it is the local name that 
determines whether or not an object exists, and since the local name has 
no meaning outside of the context boundaries, objects cannot move from 
one context to another. An object can be copied into another context 
but the resulting copy is a different object (even if the original 


object is destroyed). 


There are a number of reasons for using local names in contexts. 
The first is that autonomy in naming is desirable, and often necessary, 
if the distributed system can be partitioned or a node can be detached 
from the system while continuing operation. If a centralized naming 
mechanism were used, it would have to be accessed every time a new 
object were created. If, on the other hand, the available namespace for 
objects were divided, in particular, along context boundaries, Saet 
context could assign locally the name for a newly created object. — By 
combining this with a globally unique context name, globally unique 
naming can be achieved for objects. The Sdcana reason for using local 
names for objects is in order to save space. Since the model of the 


distributed system contains the assumption that there will be many 


Fes 


contexts at least one per node and probably more, the namespace for 


ebjects will be sania: and therefore the names.can be smaller. 


As mentioned in Chapter 1 all objects are typed. ‘An object of 
base type can be considered. ‘to contain ite values, ‘while: one of extended’ 
type, any extended type, can be viewed | as. a Lage of naues “of the i. 
component objects. Since an object will ‘reside in the same context Stor 
its whole lifetime, the names ned: for ‘the components: can ‘and. by . 
assumption, will be names that are “tooal ‘to that context. ‘Permitting 
objects of extended type to contain only ‘lecal: ‘names s provides a “simpler 
and more elegant medal than allowing two different singe ‘of names, 
depending on whether or not named component is local or foreign. 
The simplification is conceptual ag well as in implementation. In 
addition, using only local names allows for. che possibility of. using 
capabilities provided by the local, context. as, additional, peapection.. 
beyond what might he pusetana -by. protection eanatradata. impose. On: 
message flow.at the context. boundary... Therefore, an object. of extended 


type contains only a list of local names... 


The function of the context is to resolve he namés ‘used by the . 
objects of extended type. In those cases “where tt ‘ta desirable, 
containment by naming foreign c components should be available, that is, 
objects that reside in another context. Of course, since, as was stated 
in Chapter 1, communication between contexts can only be done using | 
message passing, the names of foreign components can caly be packiven in 
messages. It is also the case that such foreign components can be 


_ accessed only by sending a message to the correct context containing a. 
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request to perform a single operation on the object. If names of 
objects can be passed outside the bounds of a context, objects can be 


shared across context boundaries. 


Now, it was stated that names within objects are only local, 
resolvable by the local context. This means that contexts must be able 
to contain (map from local names into) two forms of names. One form, as 
already stated, is the eaaeeaias name to be resolved by the kernel of 
the local node. We will call this a storage name. The other is the 
foreign name that needs further resolution; the current context is not 
capable of such name resolution. This kind of entry will consist of the 
name of the foreign context and a name that is local to that foreign 
context. The implications of this form of containment for sharing have 


been mentioned in Chapter 1 and will be explored further later. 
2.2 Abstract networks 


We now have arrived at the following situation. We have a node 
within a distributed system. The naming environment that it defines 
contains objects that are all uniquely named. From the point of view of 
the user this world of objects is composed of partitions which we call 
contexts. An object exists in exactly one context. Each context has 
the ability to name the objects it contains independently of all other 
contexts. All communication among contexts is exclusively by means of 
message passing. Thus our contexts are taking on the appearance of 
nodes in a network, resembling the abstract network postulated in the 


recent work done by Svobodova et al.[19] 
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Contexts allow for two types of protection. First, they beeside 
a simple means of limiting error propagation. Second, they allow 
itiplementation of arbitrary protection constraints on the context; 
Githoeieaa ca to have message processed and operstivad: pectorsed in 
one’s behalf within. a context can be constrained to. any desired dairen: 
The second. <— of protection makes the first possible. As ‘tong as 
me saages are not sent outside. a context, any errors. that may occur 
inside the context will remain contained within it. If errors cause 
meekages to be sent, providing contexts with the ability to | protect 
themselves to any. desired degree means that. they can. protect ‘themselves 


from external. errors. 


Drawing on the comparison of contexts and nodes of a network, if. 
two processes must communicate, it is nécesaéry: to tonsider whather or 
not they are running within the same context. A process executes 
procedures, and since all procedures are objects and exiet within some. 
context, the process must be by definition. executing a procedure from 
within a context. (We will avoid a discussion. about. whether. or not the 
context in which a process runs 1s fixed. for the life of. the process or 
not.) Now if two onireniee abe executing within the seme context, they a 
can communicate through a shared date object. ‘This ie not to say that | 
_ this is the most desirable form of commmication, but’ that itis. 

- available, Oa ane other hand, if two poccaates 4 seperate contexts 
wish to communicate, they. have to. do. at by mosaage passing. ve are 
viewing contexts as abstractions ‘of nodes, and’ have postulated that 


processes communicate between nbdes by seadtrg absuages ‘through the. 
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commun ication medium. Thus sharing an object across context boundaries 
exaggerates the differences between the two kinds of sharing; if an 
action is to be performed on object 1, which is local to context A, from 
context B, (1) a request can be sent to context A for the action to be 
taken at context A or (2) a request can be sent for a copy of object 1 
to be sent to context B in oder that the action be taken on the copy. 
These two forms of sharing have existed in situations where direct 
access was possible from both sites, but message passing accentuates the 


differences, 
2.3 Contexts as objects 


As mentioned previously, the contexts must be nameable by each 
other. It was stated in Chapter 1 that an object has three attributes, 
name, type, and value or state. In light of this definition it is 
possible to soueides that contexts are objects, in the same way that 
other types of data are objects. There is something inherently 
different about contexts though; the domain of the names they can 
contain is different in nature from those contained in data or procedure 
objects. The latter two contain only names that are local to the 
context in which the objects exist. A context, on the other hand, 
contains storage names for those objects that exist within it, and pairs 
of names (name of another context and name to be resolved within that 
other context) for those objects that are known to objects it contains, 
but are not local to the context. Thus, context is a special type of 


object. It must be a basic type since it provides one of the interfaces 


between the user and the kernel. We will see later that parts of the 


pm hae 


‘kernel must be able to access parts. of the. context. Aype. manager, In. 


Chapter A we will discuss those operations fows the . type context, that, we. 


will need to achieve the copying discussed: ia Chapters..3 and Ae 
2.4 Summary 


This chapter has discussed. three distinctly different: possible 
views of contexts. .As.will become clear. 4n Chapters 3 and 4, we will. 


use all chicas simultaneously. A context contains the object we wish to. 


share by copying. In order to achieve the copyiag, it is necessary to * 


perform some operations on conteats as objects: aad ‘sometimes. request 


that contexts send mesgages. te each other - AD, aequize foreign. components 


as part of copying. Thus, we will slip among. the. Aifserent. viewa of | 


contexts without being; explicit about it. | 
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Chapter Three 


The Copy Operations 


‘In ciisntae 2 we developed « a better idea ae what a _Sontext is. In 


C 


particular we can imagine contexte to be wodes in an abetrace network. 


Inside each euch node isa namespace ¢ containing oplects: As mentioned 
in Chapter 2 containment ea sharing ¢ of E components ‘ean occur across 
context boundaries. It is also the case chat procedures | can ‘ba tavoked, 
ee 
requiring parane tae neers across context boundaries. Finally, 
multiple copies of an- aniece for reliability and gare aes must be 
considered. In art pheee cases copying mu muse occur when context - 


boundaries are crossed. Therefore, the semantics of emis needs 


iavastduation: 


Copying must be chardtte’; if a copy of an object a to be created, 
it must be indicated precisely in which Pals da me original and the HE Op. 
are the same and in. which ways they are ‘different. Clearly, ‘the values 
should be the same. But aleo, the behavior Laima be as similar as 
possible. In other woress if an object and its copy are a the same 
state and the same sequence of operations is pavtorned on both, they 


should be in the same state giueiueae This means that any sharing 


_ that occurs in the structure of the original should also occur in the 
1 


copy. 
1. As we will see later CLU[11] currently does not do this. 


ds 9 


As mentioned previously, we will provide several different copying 
facilities. In a sense, the most Hiske Cae cntvats on is what we will 
eail copy-one. This copies Peer arran top. Level of an object of extended 
type. The other copy operations celta id ebebane he built up out of 
copy-one eee ee by explicitly requesting copy-one for each 
component object. The second is the most encompassing, ¢ —fulls it 
involves copying the whole object, the ‘complete structure. The third is 
something between the two, copy-full- local. It : involves copying just 
that part of the object that is local to the context containing the 
object itself. There peer at Tone will ‘be Atecussed in, detail further on 
in this. chapter and in Chapter le. Consideration of ‘the apparent 
relative usefulness of the three operations is postponed until Chapter 


S208 


There are a number of. goals to. ner ia mene waite SARTOESES 
copying mechanious. “First, since ‘chete ‘will ‘he more ‘than cone type of 
copy operation, we should economize on mechanism, avd attempt to provide 
a single mechanism to achieve all the copy operations. Second, since. 
all passing of information from one context bo aso thes nals occurs 
through geGadcee: the mechanisus should keep down the quantity of 
separate pieces. of information. that. must move between the two ecoeestes 
in order to keep the number of messages under control. Thus, the 
representation of several components des tacginkal ‘together in a single 
message. On the other hand, it seema useful to copy i object 
piecemeal. There are three reasons for this. First, this will help 


reduce the amount of putter: space needed at ‘both. ends of the message 
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passing ened ity. Second, it will allow processing at the receiving end 
to overlap oie sending. Third, it may reduce the amount of. information 
that may need to be retransmitted, since the bigger tne Ganease. the 
higher the possibility of an error. ‘Both of these become important when 
a large shount of Yaforsatten must be passed during a pee operation: 


It must be remembered that since we are assuming that. all objects 


are typed, an object can only be manipulated through use of operations 


“ERE 


defined for its type. Therefore the copy operations must be defined for 


each type of object that may ever need to be copied; on the other hand, | 


a different kind of copy, an internal one (create-image) which wil] be 
discussed later, is sufficient for types that are and will be only 


components. 


The chapter has the following plan. Section 1 provides a brief 
description of the copy operations that extet for the basic types of 
RECORD and ARRAY in CLU(11] since our copy-oue and copy-full are based 
on them. It also discusses other copying algorithms. Section 2 
introduces the algorithne developed in this reaggrch, Sectiona.3 and 4 
develop the details of the algorithms for the sending and receiving 


contexts involved in a copy. A detailed example is presented in these... 


two sections. 


3.1 Existing copying algorithms — 


As we have mentioned previously, CLU[11] provides a good. base for. 
discussing copy operations for extended types. CLU is-a strongly typed 


language. This brings with ft the impliéation ‘that all operations are 
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type specific. This means that there are no generic operations that can 
be used on an object. On the other hand, copy operations are defined 
fot most of the basic types of abstractions and type generators. The 
two types that have interesting copy operations are atrays and records. 
These are scecailp-gemevaceteee infinite classes ‘of nutabie types of 
ek (This means that they can be aed. te’ peserake types based on 
any other types.) For each, array and record, there are two distinct ‘a 
copy operations, copyl anid copy. The semantics (and implementation) of 
| the array$copyl are the same as those of the record§copyl. The same is 
true for array$copy and record$copy. Thus it suffices for the remainder 


of this discussion to use the terms copyl and copy. 


The simplest way to describe the behavior of the two. copy 
operations is to give an example. Figure 3.1 depicts a wiitable object 
in CLU. The object contains two parts, the header, containing the 
description of what is to follow (specifically, the reptype, which 
indicates the form of the represéntation of the Sb ject, and the length) , 
and the actual representation dt the object. This figure depicts an’ 
object that is a list of references to other objects. ‘A reference is 
composed of several flag bits, something under I0 bite to describe the | 
type of the object named by the reference (this actually is an index 
into a table of pointers to descriptions of types), and the address of 
the object. The copyl operation creates a new object of the same type 


having all the same references. In other words, what is returned by the 


1. We are proposing in this thesis three additional mutable basic . 
types, contexts, message~contexts, and images. The latter two will be 
discussed in detail in this and the next chapters... 
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CLU object 


j sseeree | ten | 
flags address 


references 


Type description — 


Figure 3.1 A mutable CLU object of extended type. The header contains 
the reptype, in this case references, ‘and the length, in this case the — 
number of references. The representation of the object is the list of 
-feferences that follow the header.” The only place in which the type of 
an object {s stored is:in a reference naming the object. 


copyl operation is a new reference having the same type as the original, 
but a different address, and the object at this address has the same 
“contents as. the original object, i.e. the new object points to all the 
same objects the original does. The copy works as follows. First, a 
pees is performed on the object to be copied. Then each reference is - 


picked up from the new object, and a copy operation is performed on this 
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] ‘ 
component object. For each component, as it is: copted, the new 


reference is used to replace the old one in the copy of its. containing. 
object. This process of copying componeats couttouat-oetii- copies: have 


been made of all the lowest level basic type objects. 


There are several problems with the copy operation. The first one | 
is a semantic problem. If sharing exista within a record and the 
record§copy operation is used, this sharing will not be present in the 
newly created object; an objeet that ‘is shared by two components: will be 
copied twice. Thus the behavior of the copy may not be the same as 
that of the original object under all operations for the particular te 
type. In order to achieve sharing that will be copied, a aitfereat ee 

“operation must be implemented that takes cognizance of where sharing is 
to occur. The second problem arises from the: iaplenentat {ou of ‘the CLU 
environment in general. The lifetime of an object ie no longer cine the 
lifetime of the process that. created it. A.copy ef the object canbe 
saved in some form in secondary atorage, But if the ‘pioeess that created 
the object dies and a new process wants to retrieve ‘the isiforaetica;, it 
will by definition be in a new object. The name used to identify an 
object is unique at a given time by virtue of its coutainiag an address. e 
When the state or value of an object is stored or ‘saved, all the ie 
addresses are modified so as to be relative to sone Base address 
attached to the entity being atored. ‘Thes the dames: used by a process 


. for objects can never get into secondary. stories Whee ad object ‘ts a : 


ot. This: description conforms to the inplenentation of CLU on the DEC20_ 
system at the Laboratory for eras tad Science, MIT. 


peteievea from secondary storage, it will be given a new name or 
reference (address) based on its new position in primary memory. Now 
the object really has become a new object having the same structure as 
the old one and which might be considered to be a complete copy of the 
original. In this thesis, the assumption has been made that an object 
can have an existence beyond that of the process that may have created 
it. Therefore, the object must have a name that is not tied to the 
creating process, such as an address in the primary memory allocated to 
that process. If the name is not tied to a shyaiedl address, we can 
arrange the naming mechanism and its interface to the storage mechanism 
so that the physical location of an object can change without changing 


the value or content of the object. 


In ‘addition to the copying provided in CLU, other copying 
algorithms must be examined before devising one to fit the particular 
needs of this research. One approach that must be considered is the 
copying done by various garbage collecting mechanisms. An important 
such algorithm is that suggested by McCarthy[12] and then later used in 
LISP 1.5{13], MACLISP[14], and other list processing systems. This 
algorithm passes over the information three times, first marking all 
cells still accessible, second compacting or moving all the accessible 
cells into contiguous storage, thus adding all the inaccessible cells to 
the free list of available storage, and finally updating all the 
pointers, so they point correctly to the cells that have been moved. 
There are two problems with this approach. First, because the algorithm 


requires three successive complete passes over the structure, one in the 
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old location, one to move the data, and one in the new location, we 
would not be able to achieve much overlapping, of processing. Second, 
this algorithm requires many more messages than necessary as will be 
seen later. Another approach to garbage collection hasbeen developed 
by Baker [1]: real-time garbage collection, Again, as with the 
algorithms mentioned above, the original object and components are used 
to store the name of the copies. If we were to use an approach such as — 


this, additional message passing would be necessary. 


On the other hand, Bishop has developed a mechanisa similar to 
ours [2] for his compacting garbage collector. For simplicity he does 
not modify the original object. being copied, but rather maintains an 
external marked database that maps the names, of objects into the new 
copies of these abjects.. An entry in this data base for a. particular 
object indicates that it has been copied and provides the name of the 
copy. In our mechanism, the message-context provides a similar 
function, althqugh it also maintajas the list. of those objecta to be — 
copied. The. reason for this is that, Bishop followa each path to its 
end, thereby copying the lowest level components first, in fact, and. 
ending with the top level object. ‘In this thesis one of the goals is to 
send images aucqudeiy as possible, not invoking the copying recursively 
on components; therefore the message-context ia the means of retaining 


the information about which components need copying. _ 


Other algorithms for copying list structures have been developed by | 
Fisher[5] and Clark(3]. The purpose of these algorithms is to copy an. 


object of arbitrary size in a workspace of bounded size. In both cases 
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“\ in order to achieve such a goal both the original object and the copy 


are utilized: by changing the values th‘ each: sultiple times. These 
algorithms have, from our point of view, probiéms similar to those of 


~ the garbage collection: algorithas. «Thus, :we-fousd it necessary to: 


‘ao develop our own. mechan ise for. copying. in the: situation in‘whieh ail 


communication takes’ place through neasngue,: ead: where: itis desirable or 
: evebsuecessary to send pieces: 9f the copy) separatety im separate “LY 


, mesvaney 


2.2, Peoposed copy cosa arionse 


. This thesis will provide three varieties of copy ‘operations. Tyo 


ED a hs re eae 


of them are very stmilar to. the two Provided by cu as discussed io the 


ee be WBE ESE gst ERS ES, pA wene*e ee 


no preceding section. “two problems + were drought isp in ‘relation to au, 


i are oe #03 Bal? 


: pisaaed that CLU does | not recognize any soaring within « an 1 object, and, 
* second, ‘that, | as can ‘ba seen in the sening mechenison rdbed in aw, « an 


3 4 


object has no ‘existence without the Process ‘that created it. We are 
be ee Q Ces OP aa t Be She Pay eat 
asouming that | an 2 object has | an existence i ert to ite context : inatead. 


It is the context that. determines waether, or “not an | object existe. 


ae) enh 


As we have discussed: Pe ae with each local a. 

context -will-be a:name vf ota: of: tHe bandera fuld-eoge:pairiof the fora: 
{context, local name}, ora storagt nake that uniquely Adedt ities the’ 

obj ect to | the “storage weaned in otdet that. the object: dait-actually'be : E 

accesééd. Also, “an ment ioned® previously; when dn ‘object #6 shared<(by: 

naming) ‘by two" ‘compénents of* “another dbjéct Wiieh de: ‘being ‘copied: ‘that 


the sharing: should act be Lost in aaktag. the: seppe!- eee Bend Rd 
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We will call the two copy operations that are modelled on CLU 
eooeconavawa copy~full. The third copy. operation is the 
copy-full-local. This operation ie the same ae the copy~full except: 
that: only the original object and. those compomenta of it ia the same 
context as the original object will be copied, wadle for the foreign 
components only the names will-be sent, “Ageia, the best way to explain 


the details of these operations is to consider an example. 


Let us first consider Figure 3.2(a). Throughout..the remainder of 
this thesis the abbreviation “L=-N" will be used for "local-nane" and 
"s-n" will be used for "atorage-nane" in naming object during the 
discussion of examples and figures. We wish to copy the object in 
context 1 having a local name of L-N- 18 to context B. Figure 3. ny 
shows the structure of the bblece ie 18 as a ‘block ddagren. Now, in 
order to oo a copy-one operation ¢ on Lt 38, to. create a ‘copy ia’ 
context 5, four names Lecal to context 5 must be chosen (here L-N 
31-34). Figure 3.3 depicts what will be in context 3 after the copy-one 
operation; there will be a copy of L-8 18 of ‘context ‘1 and for. each 
local name used in the copy in context. 5 (heed well bk wXbeewence back _ 
to the original componeat. Thus the firet nage, whea. followed through, — 
points to L-N 8 in context 1, the second, to L-N.12 Ta wouceds 1, and 
the third to L-N 9 in context 3. The first two. caa be. resplved to 
storage names im context 1, but the third.can ealy ia context 3. Figure 
3.4 presents the copy-full on L-N i8 ssonenpet 1. a hn, 00 att the 


context 5. Now, there are no references back to the original biesta: 
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context l context 3 


S-N 1 
S-N 2 
S=N 3 
context 3, L=-N 9 


(a) The names in an ‘object, its ciaiponentss. and the eédevint contexts. 
The contexts contain mappinge: between ldcak ‘namessand..storage:or full | 

| names as well as objects."L-N" ‘and "Sen" -ate-abbréViations for 
"local-name" ‘and "storage-name" respectively. 


(b) Block diagram of the structure of the object L=-N 18 of (a) 


Figure 3.2 An example of an. object. 


ee ae 


context 5 


S-N 6 
context 1, L-N 8 
context 1, L=N 12 


L=N_34 


Figure 3.3 The results in context 5 of a copy~one on {contextl, L-N 18}. 
of Figure 3.2 to contest 5. The,context centains objects as well as a 
mapping between local names. and. storage: or fubk names. ."L-N" and "gan! 
are abbreviations for "lecal-neme" and De een ericae Faspectively. 


but also | we have. ldat the fact that--one of the: habig fclmctaad wae. See a. 
context separate from the rest. On eee other hand sharing bee: been 
maintained. Figure 3.5 dsphcee tae copy tue acai Ge Ua is Sisaonceet 
1. Here apedn five local names are needéd in context 5, but the 
component that was in context a. since that ‘is not the context that 
contained the object originally being copied, was not copied. Only the 


name of that object has been ‘passed to the receiving coutent. 


At each myeteet node in the system, there must be in addition to 
the set of contexts peenterae there a kernel that supports such basic 
functions as message passing between contexts, communication with the 
hardware network underlying fhe system, one managenent, and 
allocation of other physical 1 resources that are  haced ‘among the 


processes running in different contexts ow the gis Hoda.’ A kernel will 
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context 5 


Figure 3.4 The results in context 5 of a copy~full on {context 1, L-N 

-. 18} 3 Figure 3.2 to context 5. The context contains objects as well as 
a wappting between local names and sto or Fuld names.‘ li Foe a and: - : 

“S-N"* are abbreviations fee "tocal~nan Als I rE are . — 
aaemeaseA ie 


_ also provide mechanisms for enforcing security constraitits of the 


contexts it supports. 


In copying an object from one context to another, images are | 
created within the sending context as previously described. They are. 
then passed to the kernel of the sending context... We will postulate. a 
message handler that deals with all the problems of passing messages 


- among contexts on the local node and into and out of the network for the 


ae ten 


context 5 


S-N 6 


S-N 7 
S-N 8 
context 3, L-N 9. 
S-N_ 10 


Figur 35 5. The results in context. 5. of. ‘a gopp-fullo, . 
Lei. is} of Figure 3.2. to context B... the context cont = : 

well as a mapping between local. names and storage ot full names, "L-N" - 
‘and "S-N" are abbreviat iong for "Local—name" and "storage-name" 
respectively. ee nee. 


gis eae ee gs 
local contexts. The message handler must determine how to find the. 


receiving context. If the receiving context is on the same node, the 
network need not be involved at all. The messages passed out of the 
sending context will simply be passed directly to thé receiving context. 


If the receiving context is not on the local node, the message handler 


1. We are assuming not only that the architectures of all the nodes 
are the same, but also that the specification and implementation of the 
extended and base types of objects that can be copied are the same on 
all machines. By this we mean that the representation of an object of 
extended type will be composed of the same component types on all nodes 
between which the object can be copied. The problems caused and avoided 
by such a restriction will be discussed in Chapter 5. 
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must prepare each message for transmission through the network to the 


correct node. 


3.3 The copying algorithms 


The procedure that will be followed will be-similar for all three © 
types of copy operations. When it has been decided that ati object “is 5 
be copied, the first step will be to creates messdge-content. A 
me ssage-context is’an entity that is gtowablée and “will have only a short 
lifetime. It is a mapping between the index ofan entry and the value 
of chek entcy: An entry is created as folfews: each name in the 
original object will be examined’ to: ftmd the’ full ‘name, {context ee 
‘local name} pair, for tt. This will become ‘an entry in the 
message-context 4f it is not there “already. ~The <entty associated with 

‘Addex 0 will be the full name of the top level object being copted. 
Meanwhile an image of the object will be crested ‘having in place of © 
each name in the object the index of the entry in te message~context — 
praneunane the full name Pes the component object. The image of each 

component will have attached the ‘aden used in the message-context. 
ssa object will also have the type sbeecnens: hes an saee od the 
ovigtaal has thus been created and an entry for ac has been meee in the 
message-context, it is ready to send. At iis point, an image of the 


next es Sao named in the message-context is created An. the same manner 


1. This work does not deal with the communication protocols of the 
network, although of course the message hahdler ust know them. The 
copy operations can know nothing about these protecels nor about the - 
degree of reliability they provide. We will discuss reliability at a 
later point. a * ee a ia 
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as the top level object using the same message—context, thus adding 
entries to the end of the message-context when necessary. This is 
frépeated until an image has been created and sent for every object named 
in the message-context that is to be copied. The message-context will 
Secvile the inaese.oe theseobjects..to he canted as components. For a.. 
copy-one operation, the copying..is sislyce ec fepnue nai aue top leyai 
object. Once the image. of the abject hag. heen gent, an image. of the 
message-context must also be sent, in order to.create the correct . 
entries in the receiving context f6r the.aencs in the object being 
copied. For a copy~full, once images for all the. ‘components have been 
created and sent, nothing more needs to be sent. ‘The mesaage-context. is 
of no more use. Finally, for a copy-full+local operation, all the 
components that are in the sending. context wild, bescopladsiand o, partial 
image of the message-context containing the indices and entries for the 


foreign references must be sent. 


The image created for each eedece eepied will have a two part 
header. One part is the index of the object’ ‘g name in the . 
message-context. This would not be necessary if we could guarantee that 
all messages would be received in the game order they were sent, 
however, such an assumption would be ea. me other part 
of the header is the type of the particular object to vaich the header 
is attached. Again this should not be necessary’ in wat Canes assuming 


that messages are received in the order sent; The reason for this ts 


1. This assumption would put additional burden on the lower level 
protocols, and since the overhead of sending the index is low, such an 
assumption is not considered necessary. 
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‘that if the order of arrival is predictable and the types of the 


a 


components are already known, ‘as the taages “arrive ‘their types will be 
known. However, ‘if the receiver Lo: expecting an obsect ‘of type any, sthe 
obj ect being received: must have. ae type: attaches : tos hoy: tn-order that :: 
the receiver: caa: ‘hand it to the correct: type mankgawis In ‘any case, . even: 
if we. could sLanace the teagoning. juat followad fer includiag bath perts : 
of the header, they can be justified on the. grounds that they provide... 


redundancy that can-be used for reliability. at ae 


We will now examine some examples for a | better ‘understanding of the 


algorithms. The object ‘to be copied again “will be L-N 18 ‘of Figure : 2 


E Figure, 3.6 Pence the i operation. The message-context ds set 


ete re Take eld, Oh S 


context 1, Ln 18. 
‘context 1, Lem. Bao 
context Ae — 12: 


‘Figure 3.6 For the copy-one operation, the, images. of object 0 and, the. 
meskes oecc sks (without its first entry) will be sent in copying 

' {contestl, L-N 18}..0f Figure 3.2. The abbreviation ."L-N" is used for. - 
“local-name". ; . : 


up with. the patxy for the object. being. copied. ie content. Is iis * is 


first looked up. and found to be local to., that content. Hence. ite full 


name de. {context i. L=N. 8}.- This entry. te put Ange | pool -maszege-content 


- 49 ~ 


an since it has index 1, a 1 ig put into. the first position in the 
Saag ie L-N 18 being created for sanding, - ‘Then the full name is found. 
fot Len 12 in context 1; and, since it is net abkready in the. 
. wesaage-context @ second entry is made, and. another 4ndex is put into. 
othe dmage. Now, wien L-N 17 is” ‘Sol Lewed; -itets Steeveced:that: cativer’ 
than -a storage name in the context, there ip ancther {context name, 
local name} pair. This, then; is used as the “full seme to put inte the 
message-context in the same way as the other full names. “ihe header for 
the image of object L-N 18 contains both the type and ‘@ zero. Now, the 
image and the message-context can teas sent (in ‘separate. peehenete, if 
desired, as Leng as there is some means of telling the terelvar that cha - 
two really belong ees 

The copy-full operation is the most encoapaseing ‘ag the three copy 
operations, and as such uncovers problems not sneowmterad with ‘the. other - 
two. First, the problems associated bl ae shared eoepernats appear. 
(This was not a problem in the copy-one, although we will eee it also in 
the copy~full-local operation.) We want to be sure that a11 such 
sharing is maintained if that is desired. The message~context will do 
this for te Second, we must consider the probindetos ‘handling forsiga: 


components. (This is not a probiea tn either of ‘the other operations. J 


1. Some optimization could be done here. First, since, only one 
object is being copied the zero in the header is unnecessary. Second, — 
if no component ‘names the-original obfect ¢ the entry for tt in the ; 
message-context need not be sent. Third, we really do not need to. send. | 
the meseage~context separately « Lietead, -we could wee the full names. 
for the references, thus tnctesies: the message—context information in 
the image of the object. 
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In this case, in addition to the problems associated with acquiring a 


copy of a foreign component, we also must be careful to maintain sharing 
‘coapadenta across context boundaries. In order to do this, a copy-one 
operation should be performed on any foreign component. ‘This means that 
only the top level of any foreign compdnent’ pliis ‘the names it uses wilt’ 
be acquired. By this means the message-context will discover all 


sharing, even that involving foreign componetits. 


The copy-full operation is exemplified in Figure 3.7. Again, as 


ge-context 

“context I, L-N.18 
‘context 1, L-N 8 
context 1, L-N 12 
context 3, L=N 9 
context 1, L-N 7 


_ Figure 3.7 For the copy-full operation images of objects 0, 1, 2, 3, and 
‘4 will be sent, but no image of the message-context need be sent in 
copying {contextl, L-N 18} of Figure 3.2. The abbreviation "L-N" is. 
used for "“local-name". etre 


in the copy-one, the message~context is ‘created with an entry for - 
{context 1, L-N 18}. Also, again, an image is created of L-N 18. Once’ 


this has beén done, and the header of type and index 0 have been 


er R as 


attached to this image, it can be sent off. Now, the next entry in the 
message-context, {context 1, L-N 8}, is picked up and an image of that 
object is created as with the first. It is of a base type, and 
therefore its value will be copied. Again, the header will be attached 
to it, this time containing the type of this object and an index of 1 
(which is the index of its entry in the message-context). Now this 
image can be shipped. Once an image of L-N 8 has been created, we can 
pick up the next entry in Sig message~context. This is {context 1, L-=-N 
12}, which is an object of an extended type. It contains a list of two 
names. The first is L-N 8. When the full name is found for this, 
{context 1, L=-N 8}, and it is compared ith the entries already made in 
the message-context, it will be discovered that there already is an 
entry for that piece: Its index is picked up for the image of L-N 12, 
but no new entry is made in the message-context. Now the next name in 
L-N 12 is handled. It is found to have a full name of {context 1, L-N 
7} which is not yet an entry in the message~context, so an entry is 
created and the index of 4 is used. Once the header containing the type 
of L-N 12 and an index of 2 have been attached to the image of L-N 12, 
this step of the operation is complete. The next object to be copied is 
{context 3, L-N 9}; a copy of this must be acquired fiod context 3. 

Once that has been done, an image can be created for this object having 
in its header the name of the type of {context 3, L=N 9} and ae index of 
3. The copy operation from context 3 must be a copy-one, although for 


an object of base type as in this case, it makes no difference. 
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There are several issues that need mentioning here. First, the 
copy of {context 3, L-N 9} will not be kept in context 1. If such a 
copy were kept in the sending context, we would have a situation in 
which the copy-full operation would have side-effects on the sending 
ceutexey Vite is clearly cueabaesbies Second, there may be problems 
with acquiring that copy from a foreign context. It will, at least, 
cause some delay; at. worst, it may be impossible, causing the original 


copy-full to fail. It is for this reason, and we will discuss it 


further later, that we have added the copy-full-local operation. 


To resume our example, we will assume chat the copy-one on {context 
3, L-N 9) into context 1 has been completed successfully. We now can 
proceed to {context 1, L-N 7}. This is another object of a base type. 
The value will be copied as with L-N 8, and the header attached. Now 
when we look at the message-context, we see that all the objects named 
in it have been copied and their indices attached to them in their 
headers. Therefore we do not need to send any part of the 
message-context to the receiver of the copy, and the message-context is 


expendable. 


As was mentioned before, the final copy operation is the 
copy~full-local. This seems to be particularly useful when one cannot 
or does not want to involve other contexts. An example of the 
copy-full-local operation is depicted in Figure 3.8. It is quite 


similar to the copy~-full operation. First, the message-context is 


1. Of course, copy-full operations will always have temporary 
side-effects. 
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message-context 
context 1, L-N 18 
context 1, L-N 8 
context 1, L-N 12 
context 3, LeN. 9> 
1, L-N 7 


[valve _ 


Figure 3.8 ,8 For. the cope-fuli-iocel poaracion Suge of objects 0, 1, 2,. 
‘and 4, anda partial taage of the meseage~context containing the fourth 
renee (3, {context 3,. LN 9})} 5. WILT be seat in copying (context 1, L-N 
18} of Figure 3.2. The. abbreviation | “Laut de used. for “Local=name" 


created. The. images of LN. 1B, InN 8, at 3 ben 12 are created. When it: 
is discovered that che next entry. An: the message-context {context 35° Let 
9} names-.an object ina foreign context, the image for this object des 
not created, but the entry in the message-content is marked for. future - 
reference. Finally, the image of ial 7 is created. pay time etter each 
‘image has been preated; it may: bes sent. he inage of a , partial 
message-context must also be sent containing all those entries in the 
megseae context that were marked as not copied. ‘Once all this. has deen 
sent, the monsage-coptext can be deleted and the “sender has finished | his 


er Cre 


part in the operation: 


3.4 The receiver 


As mentioned: previously, the message haniiter for the sending 


context will be passed images from the vending context, and pass them to 


xt ie on the. same | node in 


the ‘receiving context. Tf the receiving. conte 


the distributed ayeten as the sending context "ei! re ‘eontexts will 


make use of the same message handler. If the receiving context is on 


another ‘node, the ‘sending mesnage handler will pass the images out into | 
the network; “a foreign message handter® wilt’ ‘take“tare of them. Whether 
ot not. ical network was° “used, tt is in che: ‘Feceiving context that the 
images created by the: sending, context must’ be: used™ to" ‘create the actual 


we 


copibe of ge ae ‘Me will present the: » recetwing: plocedures as a set of 


oe cases each to be handed difterentiy, ‘as: thee: tei 180° many possible 


3° 


orderings of the arrivete of the paste of e copys. and we want processing 


to: bast a8-soon as ‘a receive command hae been Leaued ane i at least one 


4 


image has arrived. 


We must be able to identify each piece of a copy as Be coe of that 
copy. Back wieke will be labelled with’ ‘tte own ~ 1 type end its index if it 
is a copy of a component or the face ener as is a ‘message-context or a 
part: ‘thereof, tf the copy was a eopynone or a ‘Gopyetullétecal. The 
procedure is aia’ follies. 

1, Wren the first image (component ‘or message~context image) is © 
ready to be processed, a local receiving message-context | 
is created; ‘It wilt contains: ‘fn’ ‘gaditiow to°the index. for 
each object, the local name for that eet besa once raat name 
has been determined. ee 

2, When the message~context image arrives; its entries are — 
processed sequentially. As each entry is processed, the. 
receiving message~context Ls firet checked. “If theré is a 
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local name there associated with the index of that entry, 
this local name is. used to. find, the, location in the local. 
context to place the full. name carried by the 
message~context image. If. there. ia. no, local name in the 
receiving message~context for ‘that entry, the context must 
find a local name to refer to the. foreign, object, this. 
entry is created in the local context, ‘and. an entry is 
created in the receivi putext. for. the. 
appropriate local name “having the appropriate index. 


3. When a component image ariives, the. receiving seasage-context. 
is checked for a local-ngme to. be used for the new object. 
If a reference to the arrivir , Component: has already been 
received in another image, 2 local. nase-.will have. been 
assigned. If not, one must be requested from the context. 
Using the appropriate. local name, . the. mage. As, transformed. 
into a copy of the original object. If the object is of a 
base type, its value.is. taken. from she.image.. If-it is of 
extended. type, each name is picked up out of the ke 


Using this. name: as. an. index: into; the mussege-coutert,.4 


look up is done. If either that object’s image itself hes me 


arrived. previously, .or another, veference..to.that object . 
has arrived in yet another image, thea there already will — 

_be an entry in the receiving ‘mes. neoutext containing a - 
local name for the reference. This. wall be used in the 
copy. of the component bedagereated. If there is no. local -- 

- name for the reference yet, the context gust provide one. _ 
Thus an entry will be created in the recetving.. 
message-context, having the ‘appropriate index and ‘the. 
local name provided by the ‘context. Also an entry must be 
made in the context,..akthes ng .objeqt..will.be assigned . 
as yet; i.e., there will be = teead. name in the context 
having no other game. Aedeige: anaes on: full. name) 
associated with it. — 


4. Images are received: until there ae ‘no eile in the context 
that do not have storage nasies.or full names associated 
with them. At this point, the copy ‘has been completed and 
the receiving message-context is no. lenges needed. 

When the message~context. depicted in. ce habe 3.9 (a) is sided to ‘Figures 
3.3, and message~context in Figure 1.9 ios to Figures: sh and 3.5, we 
can see the receiving contexts for the copy-one, gopy-full, and 
copy-full-local operations after all the. mages. agua in Figures 3.6, 


3.7, and 3.8 respectively have been received. ee 
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me Sssage~context- 


(a) The message-context that must be added to Figure 3.3 in order that 
it depict the receiving context after it has received the information 
sent in Figure 3.6, the copy-one. 


message-context - 


_(b) The message-context that must be added to Figures 3.4 and 3.5 in 
order that they depict the receiving context after it has received 
respectively the information. sent in Figures 3.7 and 3.8, the ssi ialanck 
and copy-full-local. 


oa 


. Figure 9 Message-context in the receiving context. The abbreviation 
“L=N" is used for “toga -aaae”: 


Chapter 4 will explore in greater detail the support chat must be 
provised to achieve what has been earpaped this far. In particular, it 
will eeerreee the types. message-context ana image and how they can be 
used to provide those facilities the user needs while hiding what the. 
‘user does not need to know. Chapter 5 will compare the three copy 
operations and point out problems and some interesting possibilities for 


further research in similar directions. 


- 57 - 


- 58 - 


Chapter Four 


Additional Mechanism for Copying 


In Chapter 3, we » discussed algorithas for copying to pe used in. an 


‘environment of contexts as “described bh Chapter 2. We must now 1 explore 


sass 


the implications of these algorithms in. terms of ,wnat new basic types 
Sa 


are needed in contexts, what mechanians 3 are pected | as supports below the 


level of the contexts in order to achieve such copying parres: contexts, 


we 


and the inter dependencies among these entities. hes will also extend the 


copy operations to iney ie exert copying. 


“fed fonnagt-sanient and: images: 

. Two peste types of objects were deed ua Chapter 3 3 to ‘describe the 
copying operations that must be defined perce contexts: : 
me s8age—contexts and images. These two typesare basic types and 
therefote provide an interface: with the: lower; level or: kernel of the 
node supporting the context. This section clarifies their 
characteristics by describing the operations dat tase for these types. 
Language: constructs similar to those of euotin wan be: used ‘for this 


purpose. Bete ot 


As mentioned previously, me'ssa age~rontents: are” — in many ways 


to contexts. Each is a aianice. ne one kind of nanes, Local to and 
oe within™ the context, “to other kinds: OF tatien:” Message-contexts 


are used ied gage teriate FOE preperthe snagee ‘when: copying « an opdere- A 
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Poreree convene? as used in Chapter 3, is a BapEsee petyees the indices 
for entries in the message—context naa ‘the contents. “of those entries, 
that is, the full names for objects. We will modify this definition 
slightly later in this chapter when Atscussing | an Sacrana aunts for local 
copying within one context. A sessage-context | not only must ‘hace crack 
of the comnonadit objects, bet also ‘must do ome ‘other bookkeeping. 
First, it must remenber ‘how many ‘daddces: have besa” used. “Second, it 
also should remember wich componente have been copied and which have 


not. We will depend on the message-context to "provide the name of the _ 


next object to be copied. In order. to. 45 thd Pe the nessage-context must 
remember which type of copy operation ‘it ‘te ake The oe 
message-context must also oversee the sending DE: an image. of a \geloaen 
pmeaee ges Onr eer in the cases of the. copy-one = ‘copy-fuli-Local 


boacaetous: Finally it must ‘self-destruct. 


Ten ppenar hens are. Beedee 195: the. meseage-context. Some of these 
are used only: for- local copying, and therefore: will; nae be. used until. 


later in the hater: The meseage-context operations are a8 follows’ 


1. create (object-name, op-name) returns (message-context-name) : 

_ takes. as arguments. a.lecel name of a local object. andthe name 
of a copy operation (copy-one,- copy-full, copy-full~local, 
receive), creates a. message~context , and returns the local name 
for that message-context. 


2. delete (mesgage-context-name): takes as.an argument a local name- 
for a local reepugerannie at deletes it from the context, and 
returns nothing. : : : 


eo 
e 


deutvoued Goiesagerecaredeaminy, yhelés (object-naze, . : 
context=-name, index], object=local): is a CLU-like iterator. On 
each invocation with the same message-context-name it produces 
another object-name from the message-context until it has 
exhausted its supply, so that the name of each object to be 
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copied has been given to the invoker exactly once. For each 
object name produced it also returns the name of the context 
containing the object, the index of the object in the 
message-context, and a boolean which is true if the object is 
local and false if the object is foreign. If copy~one is being 
executed, only the name of the first entry in the 
message-context will be returned. If copy-full is being 
executed, all the names will be returned. If copy-full-local is 
being executed, the names of all the local objects will be 
returned. 


create-image (message-context-name) returns (image-name): takes 
the name of a message-context and creates an image of it to be 


sent to another context. This transformation uses the 


- information about the type of copy operation being done using 


this message-context, and the name of the local context. The 
image created will have its type specified as message-context. 
The index field can have any value since it is not used for this 
kind of image. If the copy operation is copy-one, all of the 
entries in the message-context except the first will be copied 
into the image. If the operation is copy-full, this is an 
error, because no message-context image is sent, and this should 
have been discovered before this operation was invoked. 

Finally, if the operation is copy-full-local, only those entries 
for which the context is not the local context will be copied 
into the image along with their indices. This then is the image 
that is sent to the receiver. 


send (message-context-name, receiver-name) : takes as arguments 
a message-context name and the name of a receiver, to receive 
the copy. This operation manages the copying; it does the 
following for each component to be copied including the original 
object. The index in the message-context of the object is 
found. If the object is foreign, a copy of it is obtained. 

Now, regardless of whether the object is foreign, its type is 
found, create-image is invoked for that type. Then the index 
can be added to the image header, the names in the image 
translated into indices using the message-context, and the image 
sent. If the object was foreign, the copy of it created locally 
will be deleted. Once all this has been done for each object, 
an image of the message-context can be created arid sent if that 
is appropriate. See the later sections of this chapter for more 
details of this operation. 


local-send (message-context-name, receiver-name): takes as 
arguments local sending and receiving message-context. It 
generates the appropriate kind of copy of the object named in 
the first entry of the sending message-context. It is invoked 
when the receiver is local to the sending context, and achieves 
for local copying what the combination of send and receive 
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achieve. for distant. copying. A sample implementation of it is 
presented later. . 


7. name (message-context-nane,. index) returns (object-name) : ; takes 
as arguments, an.index,. and. a message-cantext, ame and returns 
the name associated with that index in the message-context. If 
there is. no. such neme,,the. context is. requeated . to. provide a 
local name which later will have associated with it an object. 

This SES TAStEM: is.used in Fecelying 


8. mechive Kascsecaceniancae. ‘sendex-name) : takes ag. arguments 
a receiving message~context and an Adentifier. for the arriving. 
copy (sender-name). This. operation is the reverse of send; it 
receives images and manages the creation of the components of 
the copy, using the ABAGRE TE ApRORE in an.example later in 
the chapter. eee eho ogg ge 


9, receive- image (image-name, message-context-name) takes as 
arguments. an image of a sending. measage-context . and. a. receiving 
context and updates the receiving m e-context and the 
context. with the, contents .of .the meee. Thin ia used-only in 
the receiving context. Pah a ee 


10. next-receive (uaseauescanteur. sender~name). -ylelds. (image-name , 


typel, indexl): takes as arguments the name of a receiving 
message-context and a sender, from whom a copy is coming. It is 


an iterator that yields the name-of.an image to be received, and : 


the type and index that have been extracted from. the. dnage. 
‘header. It provides. the reverse fLunckion from next~send. 


As long as message~contexts are. used. only for. sending, and receiving 


copies of EOD IOS Ces these operations are. sufficient. 


The other new type is imag . We have discussed to some extent the 
use and form of an image, but more must be said. An image has a header, 
and is of variable size. It has twelve operations defined on it as 
follows: . | | cad 

1. create (type). returns ‘(image-name): takes. as. an argument the 

type of the object for which an image is being created. The | 
operation creates. the image, which will grow,as local names and 


values are stored into the image. This operation returns the 
local name of the image that has been created. 
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2. store-name (image-name, index, next-name): takes as arguments 


6. 


the name of an image, an index into the image, and a local name 
for an object to be stored there. These names will be 
transformed later. This operation returns nothing. It is used 
only in the sending context. 


store-value (image-name, index, value): takes as arguments the 
name of an image, an index into the image, and a value to be 
stored there. Such a value will not be transformed before 
sending the image. This operation returns nothing. It is used 
only in the sending context, but not in the examples presented 
here. 


store-index (image-name, message-context-index): takes as 
arguments the name of an image and an index which the operation 
will store in the header of the image. This operation returns 


nothing. It is used only in the sending context. 


translate-out-name (image-name, message-context-name): takes.as 
arguments an image and a sending message-context, and uses the 
message-context and sending context to transform any names 
stored in the image by the store-name operation into indices, 
adding entries to the message-context when necessary. This 
operation returns nothing. It is used only in the sending 
context. , 


send (image-name, receiver-name): takes as arguments the names 


of an image and a receiver for the image and passes them to the 
message handler. This has the effect of deleting the image from 
the context. This operation returns nothing. It is used only in 
the sending context. 


receive: is the reverse of send. It is not invoked in any of 


the sample programs, but is included here for completeness. It 
would be invoked by message-context$next-receive. 


translate-in-name (image-name, message-context-name): takes as 


arguments the names of an image and a receiving message~context 
and translates all the indices put into the image by 
translate-out-name into local names in the receiving context 
using the message-context and receiving context. This operation 
returns nothing. It is used only in the receiving context. 


9. get-next-name (image-name) yields (next-name, index): takes as 


an argument the name of an image in the receiving context, for 
which translate-in-name has been invoked and returns one at a 
time the local names in the image, each with its index in the 
image. This operation is an iterator. It is used only in the 
receiving context. 
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10. get-next-value (image-name) yields (value, index): takes as an 
argument the name of an image and returns one at a time each 
value in the image with its index in the image. This operation 
is an iterator. It is used only in the receiving context, but 
not in the examples given in this thesis. 


ll. transform-names (image~name, message-context~name, 
receiver-name): takes as arguments the names of an image, a 
sending message-context and a receiving message-context in the 
same context. This operation translates the local names in the 
image into the appropriate local names for a local copy 
operation. This operation returns nothing. It is used only for 
local copying. 


12. delete (image-name): takes as an argument the name of an image, 
and deletes the image from the local context. The operation 
returns nothing. It is used when receiving a copy. 

These are the operations needed for sending and receiving images of 


objects. Images are the only base type objects that have the send 


operation defined for them. 


4.2 Layering in a node 


Now that we have a better idea of the two new basic types that are 
the basis of the interface between contexts and the system, we can 
explore the layering again in more depth. At the system iigvels we need 
to clarify the function of two entities: the storage manager andthe 
message handler. In the kernel of a node, objects are named by their 
storage names. Storage names are used by the storage manager to name 
uniquely every object that the storage manager saneewanaie. It is not 
clear that storage names have to be unique over all time, although they 
obviously should be unique at any one time. A storage name must not 
appear in more than one context at a time, eens that would imply 
direct sharing of the object; two contexts would have an alternative 


form of communication to message passing. Depending on whether or not 


ey ee 


storage names are to have other functions such as anhineieie some of the . 
Loart ph 
security Wantea. ‘they may “be capabilities, but. hay ‘also may Se tint 


physical addresses (it objects are “not physically moved), oF 1 possibly 
names that hide the physical ‘Locations of” ‘the “cbjects, but’ proeiah no 
security (in other vords they are torgeable). "Nemes ‘that’ ‘are local ‘to a 
context have no. meaning at ‘this level; they are only strings ‘oF ‘numbers ‘ 
or very simple entities that hopefully ‘will not be sintpilaced in any 


Res 


way that is iain to the objects | “and a contexte.” 


‘The storage, manager is. the interface hetwenn, POys teas, storage and. - 
all the rest. of the  BYAL OR. There. AS, NO: <Feapon, that all. the nodes.in a - 
distributed system need to. have, the anne, implementation pf the storage... 


manager. The storage managers will be protected from each other. by the. 


; _ message. handlers and type managers, on the; various.aedes. .1t ds these | 
that must agree, and. cooperate, not. the starage menssere,. The storage « 
manager may be quite cleverly. written, to, take., advantage, OD all. sorts of | 
optimizations, such as sharing immutable. objects between contexts by 
providing separate storage ‘names ‘that’ map dato the’ sane object. It may 
use the types of objects” to help in eiiiae 4 space ‘to. ‘(greater advantage 
or reduce time vo ioeaaie for ‘moving objects between different levels 
of whcbiy. The implementation of the storage manager, however, ie not 


Paar ee tes 
eh Bui 


of concern in this thesis. 


1. These optimizations, however, lead to a cyclic dependency that ie 
undesirable, from the point.of system. verdfication,:-se.the developer.of . 
such a storage manager would have to take extra precautions. See 


Janson[9}, Chapter 3, section 3 for, a; debadled.disgussion ef cyclic 
dependencies and many of the Bron enes related to them. 
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The OrneE important entity ts a message handler. As nentioned 
above, the message hendlers must Sooperate,. The message handler will 
take the storage name of an image, and fhe name of the receiver, and see 
Shat. the message ‘handler for the. receiver receives: the image <-. ee 


the receiver is at another node, the, sending.. message handler will | 


prepare and send the ‘image through the network. Thus the message 
handler will have to know network addresses of gil relevant contexts and 
the network protocols for sending images. As far as tiie information 
about locations of contexts is cbntietned, ‘this information can ‘be kept 
in a table that is internal to the message handler;- it is information 
about which nothing else in the nodé should need to know. 


Alternatively, a protocol: such as the one: suggested ‘by Reed [16] could be 


used to find the reteivet. ame: by: interrogating directories at different 


nodes. The network protocol will be discussed tio further: than to say 


that the various message handlers must agrée upon’them. 


If we were to parallel the sending and receiving in the case in ~ 
which the two contexts are on the same node, the same message handler 
would be used for the two, but it would ‘call on ‘the image type manager 
in the pecetving Sontext, to create a new image in the ACERS context. 
The image object that was created in the sending context: should be 


deleted. The image should never appear to be in two slates at once. 

On top of the kernel containing the storage manager and the message 
handler are the contexts, As: dtacussed ‘ta Chapter 2, contexts are 
namespaces, the eddy: namespaces available to! the: uber ‘of ‘such a system. 


Figure 4.1 depicts one. view of this art atijeneit. When a context is 
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context 1 


| context 2. 


local-name storage-name 


_ user 

environ- ‘local-name full-name 
ment 

kernel 


storage manager 


Figure 4.1 Layers in the system (on. one node)’.': 
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created, 1 it will have « a certain number of local anes preassigned to 
Siva objects, euch as the type managers of all the base ‘types 
including the context ae manager, wad all Gener resources that, in the 
“£{nal analysis, ‘must. be shared: among the cogtexzts: (for example the 
kemel add-at Vthe hardware that ia to be used: bymore than one: 
context): It ig aleo possible that a context: will ‘need to have a-local: 
name assigned to itself, to do some forms of name translation, or 


receive responses from type managers, for example. 
4.3 The details of sample copy operations 


In this section we ans present™ the details of The: copy operations 
for a type manager of a epee extended opiatee We will demonstrate 
this on an example of. a hypothetical. type, * we adeume that objects ef 


Ha 


type T are mutable and-can be: cteated’ ‘with’ a vate ‘of nil] “There are 


several other assumptions we need to’make about objects of type T. 
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First, we need to be able to create objects of type T. Second, we will 
also find a need to delete objects of type T in order to avoid side 
effects in the sending context when copying under seeteis circumstances. 
This is a special form of mince: as is discussed below in die 
description ef the operation. Third, we Secs aoe to be able. to get the 
names of the components of an object of type T one at a time. Fourth, 
we will need to be able to create images based on objects of type T, and 
receive images and translate them into objects of. type t Fifth, as 
will need to be able to assign components of.an object of type T one at 
a time. This means that it must be poseibss. to create an eee o£. ‘type 
T with a ake oF nil, ‘and, insert into it coaponents one at a time. . 


This implies a need for ; storing « a “component into 4 an object af type Te 


To achieve the. copy. operations the following: sippoctiug operations 
will be assumed for type T. ..{The operations coperemaseepy~fuil, 
copy~full-local, and recedive-copy will. be discussed and exemplified 


later.) 


1. create () returns (object-name) : takes no arguments, but creates 
an object. of type T and returns a local name for it. 


2. delete~copy (object-name): “takes ‘the name “aE an object ef type © 
T, calls on the context to delete that local name-and all the 
local names contained in the. object from the. PQDEERC and _ 
returns nothing. 


3. ga t~next—name (object-name) yields ‘(aan ole, ‘tndex): takes as 

' af argument the name of. an object.of type.T and. returns one at a 
time the names and indices within the object of each of its 
components. This, operation is : iterator... 


4, create-image (obj ect-name) returns. (image-nane) Eakes as an 


argument the name of an object of type T and returns an image of 
that object containing local names that will be translated 
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later. The image may also contain values that will not be 
translated. 


5. receive-image (image-name, object-name): takes as arguments an 
image name and an empty object of the type any. There must be 
only names local to the receiving context or values in the 
image. The state of the image will be put into the object. 

This operation returns nothing. 

6. store-name (object-name, index, next-name): takes as an argument 
the name of an object, an index to a component of the object and 
the name of that component to be installed. This operation 
returns nothing. 

This is a list of only those operation needed in type T in order to 
achieve the copying. It says nothing about what other operations there 


may be in type T. 


A number of additional details must be specified. We wiil assume 
only two operations on contexts: 


1. request-copy (object-name, context-name) returns (new-name): 
takes as arguments the two components of the full name of a 


foreign object, obtains a copy (copy-one, to avoid any loss in 
sharing) of the object, and returns the local name for the newly 
created local object, which is a copy of the foreign object. It 
guarantees that a new local name is assigned to each non-local 
subcomponent name. 

2. local (object-name) returns (boolean): is a test operations that 
takes an object name as an argument and returns T if the object 
named is local to the context, and F otherwise. 

In order to implement the procedures described below, some modifications 
are needed for the CLU type any. This work assumes two operations on 
the type any: (1) type, which produces the actual type of the object in 
the any object, and (2) force, which forces the any object to the object 
inside the any. CLU provides no operations for the type any, although 


it does provide a force built-in function. Another type that is assumed 
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in this work is type. No. operations. are needed for it in the sample 


implementations in thig work. 


Now that we have a better underatanding of the relevant aspects of 
contexts, and the full complement of operations available for images and 
message-contexts, we can consider the details bt a. possible 
implementation of the three forms of copying dipcuadad in Chapter 3. We 
will begin by sean the similarities aca the operations. In | 
particular, the message~context appears to be a focal point. Since the 
aiuuagaseoncext contains the name of the copy operation being performed 
(copy~one, copy-full, copy-fuli-2ocal) and the identity of the top level 
object being copied, it contains enough information to be at the core of 
all three copy operation. The message~context$send operation aeeetins, 
this central fumction on the message-context.. ihe Sesahan context is 
created containing two pieces of information, the asain: of the original 
object being copied ead ths type of the: copy.operation. "(hater 
message~contexts. will also be created with "receive" as the name of the 
operation using, them.) - Message-context$send invokes the create~image , 
operation of the type manager for each component to be copied. When all 
components that should be sent Have been sent, an image of the part of 
the message~context naming those components not eént is created and 


sent. After some cleaning up the copying is complete. 


It is important to keep in mind that the tools provided for the 
system users. should. be as simple as possible and should not. contain any 
mechanism for which there is no apparent. need on the particular level of 


abstraction. Message-contexts may well fall into this category, but 
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they can be hidden from the creator of an extended type manager or 
cluster. A method of achieving this is to make available three generic 
operations or procedures named proc-copy-one, proc-copy-full, and 
proc-copy-full-local. These procedures will simply see that 
mesSage-contexts are properly created and sent. There is one other 
-place at which the programmer might come into contact with 
message-context; when the images are sent, they contain only names 
generated by the message-context, yet the creation of the image of an 
object of extended type should be controlled by the extended type 
manager. The reason for image creation being in the type manager is 
that what actually is sent should be type specific. There may be 
information which is node specific, that the receiving type manager will 
have to acquire later. There may be components such as temporary 
workspace that it would be a waste to send, and perhaps for security 
reasons should never be sent. Whatever the reason, image creation 
should be under the control of the type manager. For this purpose, the 
programmer will be required to write a create-image operation, which 
will see that the image is created and write values and only names local 
to the context into the image using the imageS$store-value and 
image$store~name operations. The message-context$send operation will 
later, unbeknownst to ine programmer, invoke image$translate-out~-names, 
using the appropriate message-context. Thus the Srouraimiee never knows 


of the existence of the message~context. 
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The only other pieces of code the. programmer must write are 
definitions of which copy operations. are to be defined for the type. 
Yhese operations will do nothing but invoke the appropriate generic copy 
operation passing along the paraweters. Figures 4.2 and 4.3 provide a 
possible coding of the procedures descrited in this section for objects. 
such as the top level object used in the examples in Chapter 3. They 


are written in a subset of a language based on the conventions of CLU. 


copy~one = proc (object-name: I, receiver-name: any) ; 
proc-copy-one (object-name, receiver—name) ; 
end copy-one; 


copy-full = proc (object-name: T, receiver-name: any); 
‘ proc-copy~full (object~name, receiver-name); 
end copy-full; 


copy-full-local = proc eis sci wenet Ty receiver-name: any); 
proc-copy-full~local (object~name, receiver-name) ; : 
end copy~full-—local; 


create-image = proc (object-name: T) returns (image) 5 
image-mame: image := imegeScreate ("I"); . 
for (next-name: any, index:. dat) in get~next—name 
~~ (object-name)” do. 
image$store—name (image-name,, index, next-name) 5 
end; 
return (image-name) ; 
end create-image; 


Figure 4.2 Operations in the T type manager 


Figure 4.4 presents an implementation of message-context$send; 
since message-contexts are base type objects, the message-context type 
manager with all its operations is provided in every context. 


Message-context$send is somewhat involved. It iterates over all the 


ae Gs 


' ~proc-copy-one = pro = (sbject-nanes gn any, receiver-name: any); 
dasakgec quest ce: meas: text <= 


preseaeliem rho may 3B: ica nee i. ae a 


any; ‘Hectver—neme: any); 


roe~c -full = EOC ‘od: ect-name: 
P opy bob3 sgesdbataie i 


me ssage~con land: ines 
message-context$create (ot rane, "“copy-full") ; 

me ssage~context$send” Uda bidge ositler ted 2, receiver-name) ; 

me saage-context$delete (manenge conten ame) ; 

end proc cap PEersy geet a aE 


ptoc-copy-full-local ™ proc _(object-nane? ay receiver-name: any); 
me ssage-context-nanet ae Sees, vee ae 


message~context¥create “(object- “épy-full-local") ; 
messagé-context$send (mess#age-co e ret ‘receiver-name) ; 
me ssage-cortextSdelete 7(m ; atertonaae)s 


end Proc-copy-full~local ” 


Figure e 4. 4.3 The generic ‘copy ee or pescedixes: Laie to each 
context by the *ermel. é 


1,2, She 
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names in the meteagescrnrexc: While this is happening, additional 
entries are made into- the REST OSEr CN ETERE by the 
image$translate-out-nanies ‘operation. § “Bor: sect object, the 


message~context$send. operation. requests.a.copy.of.the object if that. 


object is not ‘kocal to the sending context; ‘Once there is a tocal copy 


of the object (if the obfect was local no additfbndl’dopy will have been 


created), the type of the object can be determined and the appropriate © 


create~image operation ‘can be invoked: This Spe rato Will create an 


| image containing possibly a subset (this will ‘be discussed later) of the | 


same local names that were fin the object ftaeif. Therefore, ‘the 
programmer does not need to know ‘about “éedage-contexts in order to 


write the create-image operation. Once thé ‘fmage has béen created, ‘the 


send = proc (message-context-name; Et, receiver-name: 
for (object-name: any, context-nene; Agntext, “index: int, 
~~ object-local: boolean) in next-sead (meseage-context-nane) 
do 
“if (object-local equal F) t en 
new-namet any i= context: sudet-cony ( (object-name, 


context-name) ; Sy ae ee 
object-name it pewmames, 
typel: type : ta: any $type {cbjectrname)s. 
‘image-name: image := at eenenertme es (any$torce 
CoA NS oe 7 a 
image$store—index . (image-nane,, ‘Andex);._ 
inagestranslaten ut- nar f 


image$send (imagernana, name, Teceiver-name); 
pea (object-local equal a 
typel$delete~copy (any: force ‘(object~name)) 5 
end; ; 
if (op-code cease ae ‘not, equal ' ‘copy-ful1") then 
image~mesaage-—context: image := createrimage. 
(message~context-name) ; 
image$send (inagermoesage-context, receiver-name) ; ; 
end; 
end send; 


Figure 4.4 The send operation of the message-context type manager. 


oe 


index in the message-context of thé. object. from. which it was. created can 


be placed in the header of the image. Also, the names: in the image must_ 
be translated from local names to indices in the message-context. This 
may involve creating new sarees in the messager thntect, and therefore 
also may involve the context. After this translation has been. completed 
the image can be sent. If a saps of the object. was ssauaned froma 
foreign context, the. copy will now be deleted, and the whole procedure a 
can begin for the next component. When images. have, heen .sént, for: Pre 


-the components to be copied, if the operation was not a copy-full, an 
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image of the message-context must be sent. This completes the 


message~-contextSsend operation. 
4.4 Preservation of sharing 


An. interesting situation now exists with respect: ‘to the copying of- 
foreign components. At the context Leveiis we an control how much: .— 
sharing within an object we wish to worry :about: anross context 
boundaries. ‘If we wish to maintain albishering Tegardiess of context: 

boundaries, the context will. request a ‘copy -one of the foreign cs 


component. We will use Figure 4.5 as the basis of further discussion... | 


. Figure 4.5 An example of sharing across context boundaries. The numbers 
in the boxes pepresent values of objects. oes ce tae gt he oe 


When a context requests only copy-one for each recetee component , 
exactly one object image and a megaage-contexe faage will be acquired: 


for each foreign component. “Thus the meseage-context for the. bole. copy 
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operation will keep track of all possible sharing even across context 
boundaries (because for every component the globally unique name is 
foutid). ae result is chat the structure in the peckivina context will 
he exactly that in Figure 4.5 except that it all will be dona Géntext’: 
The Spehbia wie this is that a request must be sent out for a copy of 


every foreign subcomponent of the original foreign component named in 


the object being copied. If instead it is decided that we care about 


most sharing but are willing to trade losing some in return for the 
saving in time and messages, gcoepututlatobek can. be used instead. In 
this case, we will lose the identity of subcomponents of a foreign 
component that are local to that foreign context. Thus vaiestine a 


copy~full-local of the foreign components would lead to a final 


structure of the form depicted in Figure 4.6. In this case, many fewer. 


Figure 4.6 The resulting structure of a copy of the object shown in . 
Figure 4.5 when copy-full-local.is. used across context boundaries. The 
numbers in the boxes represent values. Thus we can see clearly where 
extra copying has taken place. 
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messages will be required if the foreign components are Larue? chee is, 
Wave any subcomponents) , but “if Siete ‘iw aaah Mise Wid adcoad context aa 
_ boundaries, there will be a greater “expense in terms of space needed ‘tor 
‘the additional copies of thie “sdbeSaipoitdh te“ ‘If there {s no interest ‘in 
maintaining sharing across context boundarfes, the copy-full operation 
- can be invoked. In this case, oily sharing that is local to a context 
or th witch two local “dompondte ‘time ‘the same foreign component will be 
"preserved. Figure 4. 7 provides an example of thé structure in the 
receiving context for the case in Maich gopyrfull ig. used to request 


copies. of. foreign components. in order, to prepare images. . Using the | 


" copy=full mey. have serious draybacks Althongh. EY, cases it may save 


Figure 4.7 The resulting structure ‘ofa copy ‘of the object shown in 
Firma 4a.5 5 when copy~£ull is used across context. boundaries, The. 
numbers in the boxes ¢epresent values. Thus we can “see clearly where 
extra copying has taken place... 


es ae 


much in time and many messages. The problem is that the foreign 
component may contain foreign components, which may contain foreign 
coiiponents. If such a structure has loops not, ouly across context 
boundaries, but across node boundaries, the infinite recursion might be 
very difficult to discover, and even more difficult to handle. Thus, 
although this may be a very tempting approach because of ite simplicity, 


it is probably something that ought to be avoided. 


meas is an came that has not yet been addressed, although it was 
considered in determining the operations earlier in this chapter. When 
a local copy is made of a foreign component , in order to create an image 
that will be part of a copy-full operation, euch a local copy must not 
have any side-effects on the local context. In other words, not only 
must the copy itself be deleted, but also the local es uned ‘to _ | 
identify any foreign components of the copy must be deleted. It is for 
this reason that the ‘deletesaopy wpcidlion Soi the type 7 wis defined to. 
delete not only the object itself, but also all the foreign components. 
of the copy, from the local context. Using the other cagas-of copying . 
when requesting copies of foreign components solves. these problems, the 
copy-full-local to some extent, and the copy-full completely. The 
reason for this is that by using these, fewer or no local aimee wit be 
associated with full names of foreign subcomponents before copies oe 
them are acquired. As we have seen there att other tradeoffs. Perhaps 
the decision as to which form of copying is used in requesting copies of 
foreign components’ should be left to the person on whose behalf the. : 


context is created. 
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4.5 The receiving end 


The operat ions needed to receive an ‘object: of type r are similar to 
those for sending except that rather than three kinds of operations, 
there is just. one. When the bits representing the Bent, mages arrive 
over the network, the message handler ‘técetves the avid places them in 
"something called a paaudo-image:. The weseagh enither sunt extract from 
incoming mauseges identifiers to be used in asseubling ‘the images 
_ belonging to the same object. When the receive request has been issued 
by the appropriate type manager, in our case type T, the process of 
creating the copy in the appropriate context can sae The 
implementatioa o£ reeeiving is similar. to seading;.again, a generic 
. operation is provided to be invoked by the reééive-copy operations of 
“particular types. Again most of ‘the contvol ts ih the message-context, 
in this case in message-context$réceive. How, ‘thé iterator used to 
drive the whole operation of receiving is bast cescoive which yields 
images acquired from the message handler. The operations of interest 
for this thesis are receive-image Si cece rex Pies r: the 
generic receive proc-receive, and message-context$raceive. For an 


implementation of these see figures 4.8, 4.9, and 4.10. 


It is in the create-image and receivé-image operations of type T 


that the décision as to what is copied ‘and tiow it is made. These two 


1. As a check that the copy was’performed correctly, perhaps type © 
checking ought to be done on the complete structure. The 
message-context can ‘be used for this ‘to’ ‘avoid@a any Loops: This is simply 
@ matter of checking that all the components of each component are of 
the correct types. < 


receive-copy = proc (sender-name: any) returns (1); 
object-name: 5 = create(); | 
proc-receive (object-name, aadder-omaas:. 
return (object-name); 
end receive; — 


receive-image =proc (image-name: image, object-name: T); 
object-name := create ()3 0.0... 
for (next-name: any, index: ‘iat) is inagefget-nent-nme 
~~ (image-name). do. 
store-name. (object-naae, index, -Rext-name) 
end; ae 
end recaive-inage; 


Figure 4.8 The receive~copy and receive-taage ‘operations ‘of the T type 


a cdane wancases datas on e~ =on = name); 
end proc-receive; . 


Figure 4.9 The generic receive operation or procedure. S 


operations ‘together provide the. type specific. ual tetas of copying. ae. 
is here that we can decide not to copy ‘séle. ‘components without ‘caining ” 
the whole copy operation to fail.. Yor instance, af some component of an 
object. is context specific, the. create: image aparaiton might. generate a 
special signal or value to the receive “rather than the name of a- 
component even in a copy~full. The signal aust be interpreted by the 
vendtvectaanes eo thet it will be ‘able to #411 in ta ‘appropriate : : 


component. This is just an example “of the reasoning that, might occur. 


receive = proc (message-context-name: message-context, sender-name: 
any) 3: | | 
for (image-name: image, typel: type, indexl: int) in - 
next-receive (message~-context-name, sender-nane) do 
if (typel not equal "meseage<context") ‘then. 
image$translate-in-name. (image-name, 
‘Nessage-context«nane) ;. 
object-name: any := naan measage-context-nane, 
dndexl); fee no 
typelSreceive-inage (4mage-nane, sny$force 
(obfect+name)); | ce 
else receive-image (Sues ime 
me s8age-context-name) ; 


end; 
image$delete (image-name) ; 
end; 
‘end receive; 


| Fi ure 4. 10. The receive operation of the: message-context type manager. 
It Er similar to the ee ees sata aaciia 


This completes. the discussion of copying | across context boundaries, 


bower g 


but there is still.one more form of copying that must ‘be discussed. 


The Vast situation that sitet acta anvea as when the copying is 
done within e@ single cantext.- For thig. we: will use much of the 
‘mechanism already in place, modifying 1t where necessary. The semantics 
of the copy—one, copy~full, and copy~fulle lobal. foe the local situatian. | 
should be the same. A® a matter of fact’ the operations:can be invoked - 
_ by using the same operation names. The only’ changes needed are changes » 
to pieces of code that the programmer ‘never sees, in particular the 
generic operations and message-context$send. To mike these operations 


work for a copy within a single context, it is necessary to simulate the 
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important parts of both the send and the receive sides of a copy 
operation, handled in a single operation, sessage-context$local-send. 
¥ot this we will use two message-contaxta, although we will see later 


that this is not always necessary. When the copy. ‘operation is rnvones 


_. the receiver-name will be the local 1 same of the copy that. is to be 


created. The first message-context will rwwasa’ ne same as previously, 
associating with the index used for a component the fub} name of the 
component. The second message-context will be used. to gsseciate, for 
each component, the index that it had in the first message-context with 
the local name for the copy, if. that is eid Thus the first 
entry will be the name passed as the recelver-can. At this point, the | 
receiver-name will be reassigned ‘to contain the name of the second 
asddage-coatext: For any component that wil not te copied (as with 
some components in copy-one and copy-full-lecal) , the. ‘local nawe of oy 


original will appear in the Sécond nessage-coutert .. 


Since, as we said before, the serid ing napeege-coubext, can: be 
thought of as representing sending. of! the: cdpp,. thi Repakving 
message-context, or in this case the second message-context,: can be 
thought of as representing the reception of the copy. Therefore, making. 
the second message-context the recelver-name, and placing.in it the local 
name of the new object are resectable. sie: ptocudionns that set be 


changed to’ achieve this are the generic. copy,.operations and — 


= 82 - 


proc-copy-full = proc ¢ (object-name: any, receiver-name: any); 
me ssage~context—name: messa e~context : 


' message~context$create (object-tiame,; “copy-full");. 
receive-local: boolean := roucwst9 ieee (reser ven-name): 
if receive-local then — 

second-message-context: message-context, : = 
message—context$creaté (#é@éivetname, "copy~full"); 
receiver-name ;= second-message-—context; 
message~context$local~send fmaeenge Context aeme, 
receiver-rame) ; " 
else message~context$send (nessage-context-nane, 

~ gteceiver=name) ;_ 
ends 7 
message-context$delete (message~context-dame) ; 
if receive-local then 

message-context$delete (réceiver-name) 

; end; 
end proc-eopy-full; os 
message-context$local-send = proc (message~context-name: 

me ssage~context, receiver: any); 
for’ (object-name: any; ‘context“tiase?. ‘context, indexl: int, 
~~ ebject-local: boolean) in next (message-context-name) do 
if (object=local equa “®) then’ ~ 
new-name: any := context §request-copy (object-nane, 
' context-name); 
Oech name = a: 
end; ae : 
typel: type : _any$type teiectsueue) 
image-name: image :* typel$create-image (any$force 
(object-name)); 
image$transform-names — (4mage-nane, mesuageccontextc Dames 
receiver-name) ; 
new-object: typel := any$force( name (receiver-nane, 
indexl)); 
typel$receive—image (image-name, mea eee 
imageSdelete (image—nane);° 
end; 
_ end local~send; 


Figure 4.11 The proc-copy-full modified ‘to take into account local 
Sepyine and and the message-context$1ocal-send procedure. Proc-copy-one and 
proc-copy-full-local dre identical td the ‘proc<copy-full except for the 
creation of the message~contexts where the approprsace pperattoo name 
must be used. 
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me neaee rennet eee rn he created. |. this. could. be included in 
iecnaga-dontastsedda: but for ease. in uaderatandiag. the Programs has 


not.) Figure 4. LL. peru these Eevisiens, 


There is a great deal of nechanisa herp. fo.achAéne something 


apparently simple. There are ‘several reascas. fox, thia, First. ‘of all, 
one of the primary goals of ANLS,. WORK. Was, : pataia. any. sharing in the © 
‘Second, using the. 


structure; message-contexts. are needed. ,ta;,do that. 


mechanisms already in place to, perform distant, SORYARS__AE wizes on 


a4 i 


mechanism. Third, as mentioned. previously, meseaae-coptexts. can and 


should be Biden: from the ‘Programmer, tase ranet Re -oresttiese- We 


As ment ioned earlier, ‘there are pone. sponsible opdiiizettons. One 


has sivesay been ‘included in Figure 4, Ws “TE we ‘wee: ‘to duplicate 
RRR CIG ANE eae ae 
strictly what is done ata ‘distance, we. would haye..two images, one for 


sending and one for receiving. We have elided thege two-into- one. A 


second is that it should be apparent that for the copy-one operation the 


two message-contexts will be identical. except for the. original entry. : 


Hence, only one message-contaxt is necessary 


could get away with none, and eimply perform | a “bit by bit copy from the 


original to the copy of the object, 
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 hetsia ty for copy-one we 


aes 


4.7 Additional issues 


‘This section addresses several additional iwaiine that arise in the 


. implementation of the contexts ae docmanicat ise pecan ‘contexts. 
1. Global naming for contexts and types of objects. 


o A problem with globaily aactqued sinabs ae any sort-is that they iaaty 
at least cooperation among the entities ssi casks ase ate 
: generation and possibly a loss of autonomy for: those entities. One 
approach to generating globally unique names isto provide a single name 
server. This cevtedialy can be made to guarentee unique names. 


Unfortunately, no new names can be. acquired: bya name client when he is 


| detached from the ‘name ‘server. A solution’to this te to diatribute ‘the 


= server, by eoh tet lopene, che neseapace | and oes each spoken tier 
client with a piece or subset a tha whole asueapace: ‘This ia ‘atta has 
i been. done for ‘objectia in the model weed in thts. research. Each context 
“Hassa aart of the Ses skee of the whole distributed. system. By | 

comb ining the locaily unique name of: an object with the. globally unique 
context’ name, Ghd eerie teas be aieigned: globally unique names. But this 
is based on the: assumption chit ‘contexts beye: globally volaue names... 
Thé ‘same: procedure: of ‘partatdoning the context namespace by nades of the 
distributed system could be used, so ieue a gads Gear’ be decucted from. 
the oyster and stit2 be able to create. new contexts. Now, tie Gindaaie 
need ee be globally uniquely named. At seme point the. process of 
d'viding the namespace must stop and: there past be: dependence ona 


central name server. It is quite reasonable to expect this at the level 
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of naming the nodes, because this may very will be encoded into the 
hardware interface to the communication network supporting the 


distributed system. 


The assumption of sibbas Gana had ales Geen pase for cones. “The 
situation here is.a little different though. ‘There is .a.certadn. amount 
of negotiation that must oceur Si oréee shod teentasidce aetee that 
they both have correct versions of the type-manager. ) Shere. ts -no reason 
that part of this agreement cannot be to egtee.os am external name for. 
the type. Neither context neads.to use the external newe-internally, 
but both wust know it in order.te ‘traneiate it: tato: the: local names. Lt 
is still p ssible that a centralized: nane server. aay, be —pecessary. 

2, Uniformity among machinss in dafining typen canid between mechioes 
- We have assumed. that: wen an object is anpied from.ane context to. 
another, not only will there be cho-eigit set of type: managers or. | 
clusters at the receiving context to recaive the: copies: of the object... 
and its components, but:.also that: the type nandgavé.-wtll be, deficed. 49: : 
terms of the- game component types, In other words:the: representation of. 
any type that is to be copied. will te the: same” tac tiene of its component 
types in the contexts between: witich it will be: copded.... It ‘may not have 
been completely apparent that this assumption; was asde,, but as. long as 
we permit the partially copying operations, copy-one and . 
copy~full-local, component: types. must be. the game... Let-us. reconsider. . 
the object L-N 18 of Figure 3.2, Let L-¥ 18 be of type Tl. In context 


1, let its third component be of type T2. If in context 5 (the 
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‘receiving context) an object of type Tl is implemented as having the 


third component of type 13, we have a problem, For the copy=one and 
copy-full-local operations the copy should have the third component’) ~*~ 


pointing to an object of type T3, but has a Componént of type T2. A 


more difficult occurs in cases in which the réprésentation of a type has 


different numbers of components in differént cditexts. ° thus vtiether or’: 
not a component (or several components) nééd to’ Be ‘converted into a ; 
dietaceat tips can be determined only by exauing othd! components. To’ 
solve this a different approach ‘to copying would ‘have to used, one ‘with: 


feet EE Ee: RB eet 


much less overlap. 


There. is also a more subtle (Problem shen creating th the copy at the: 
receiyer (in the. cages. where. ‘several images 3 are passed, copy-full and - 
copy~full-local) if the various representations of a type are different 
in terms of type of components in different contexts. Sometimes when a 
- component of a specific type e.g. T2 above, is received it will be | 
-transformed into an object of another type e.g. T3 as above and other | 
times not. Whether or not this should be done may not be known until 
all. the images have been received and processed, Much reprocessing may 
need to be done, As with the previous point made above, some degree of 


autonomy is at stake if type representations must conform to each other. 
3. Sharing code between contexts on the saime node © 


This problem can be broken into two. Problems Hepend ing on "whether 
or not the code in question is pure code or not. aa the pede can be 


impure, each context must have its own copy of every piece of code, in 


- 87 = 


particular type managers. If this were not the case, there would be 
another -waans. of commun ication between contexts besides message passing, 
and that has been excluded from our model. If, on the ather hand, code 
can be guaranteed to be pure, even though two contexts may in fact have 
different storage names for a piece of code, the storage manager may | 
actually sas these different names into the same object representing the 
piece of code. In particular, at the bottom of the network of type 
managers, the type managers of the base types (eg those that may be 
implemented in hardware) will tie pure, and therefore can be shared, As 
a matter of fact, those in hardware must be shared, unless there is - 
separate processor for each context, which seems Like“an wnredsonably 
severe lini tation. Looking at this problea slight1>” at ffedeatly, we 

must consider whether or not imautable objects ‘ean ‘te shared. We tan 


conclude that this form of sharing is. invisible.” 
4. Syachronization 


Conceptually the Series et Peaeeneeraabae sek 


problem when components are wt ip las seh tg seat 
arise. There is a problem of responsibility for foreiga locks if they 
can. be held by foreigners. “If this 1 allowed, then’ outside forces may 
impinge on the. aut onomy of a context. Wiad eek! Gide ckar'ie welt aa 
security ressons, locking “may dot ba tie eébvece eelutioa: ” th spproach: 


developed by Reed[17] appears to provide a better solution to this 
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nates 


‘problem. Reed PEOpcees that when mutable objects are modified, new 


versions of them are created and time-stamped. Thus, as oe as the 


older versions are saved, it is possible to water. to and use a 


consistent version of the object. anne also solves the Problen ‘of 


locking foreign components. 
5. The size of measage-contexts 


The size of Seseege-coutest isa Potential Laaeata One of the 
requirenente that Fisher [5] and clark (3) put on ‘their copying algorithas 
was Rounded buffer space to achieve the Copy. We have traded that ide a 


eeaiier nusber of maneares and the amend to process da parallel. 


although we have considered ne problen of the size of meseage-context 


in developing the algorithms presented here. First of all. we have 


eliminated, as ‘much as possible, actually copying the message-context. 


Second, we expect that the system will sippork a larger quanctey of and 


more useful base types than CLU[11], some of which will be larger in 


order to jevokd having to DEeae every. object into the imnuteble base 
types. of CLU. For instance, it may be useful to consider arrays and 
records of base types to be base ‘types. ‘As mentioned in partise 
chapters, we consider. contexts # and nessage-contexts to be base Eypee: 
This means that when a ueseage-context, is sent as part of a cOpy-One: or 


copy-full—local, it need not be broken apart into. enaller pieces. More 


research needs to be cone to determine additional base types. 
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6. Types of component objects that should not be copied 


An object of a particular type may include components that should 
aoe tbectopied: alehougs the object itself may have a copy operation 
defined on it. The reasons for this may be hater us << Yor example, ous 
of the components of a procedure may be its workspace. This certainly 
should not be copied. Or, a table that is to be éiatoeieed- for a. 


local context is to be copied. Some of the components should be copied, 


but in place of others flags should be sent, 80 that the type manager in 


the receiver will insert the correct component in these spots. We have 
provided the hooks for Panglsne, this problem, in the form of the 


create-image operation that the impleuenter of ‘the type manager must 


provide. This - means that type specific image creation: is performed, aad 


therefore can be written to provide the desired flexibility. 


4.8 Summary 


This chapter has presented in greater detail the sending and — 
receiving operations needed to copy an object. To this end we defined 
two types of objects, the image and ihe maasage-context The image is 
the vehicle by which we pass the value or atate of the object from the 
sender to pis receiver. Other work{11] uses the terms encode and decode 
to describe the operations of creating from the original an image in 7 
order to create a copy. The aessage-context is the means by which we. 
retain any sharing in the original structure in the copy. In addition, 
it is the means by which we avoid looping infinitely sitién copying cyclic 


structures. 


The remainder of the chapter detailed how one might implement the 
copying making allowances for foreign components and for local copying. 
In order to do this, a number of operations were assumed to exist for 
both the context and the hypothetical extended type for which copy-one, 
copy-full, and copy-full-local were then defined. An important result 
of this chapter is that what needs to be written by the implementer of 
an extended type, in order to provide these copying facilities, is 


minimal. 


ae Qf 
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Chapter Five 


Summary and Conclusions 


5.1 Sica cy 

We are now at a point to. review what has been accomplished in this 
thesis. We began with a model of a-dietributed system. It has asa 
hardware base a network of computers. | Each: nede-n this network 
supports a kernel, the local system software. On tap: of this we 
" postulate ‘one or more contexts at each node. A centext can be viewed in 
| several ways: as a namespace in which processes can execute, as a node | 
in an abstract network (with communication anon Suen seas nodes 
only by message passing), and finally as objects in a ‘world of ad dase 
objects. ‘We also ‘assume that. the typed objects goarasaed in contexts 
- may not migrate One contexts. Given this model of ‘the systems we 
investigated sharing. Since we do allow antag across context 
boundaries, sharing is possible. However, sharing of foae ee components 
is limited to the nol towtas two “eye passing meseenee requesting 
operations to be done on che object io the foreign EOntext, or by 
acquiring a local copy and peetcre ce operations nocelly on the copy. 
In the first case, the payetcas, ep ject is shared, and oy mutations of 
the object caused by one of the sharers will be visible to the other. 
In the second case, since a copy of ‘the object: is passed, AT EROuEN the 
information content of. the object at “the time a - eopy is made is shared, 


the Bereteet object is not and ehavetora any 7; changes made by one of the 
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sharers will not be visible to the other. In spite of this, since all 
communication must be done by message genbiag: sharing by copying may be 
the more desirable approach for a number of reasons. First, message 
passing is likely to be expensive in terms of both time and space. 
Second, if the two contexts between which messages are passing are on 
different computers, since we have assumed as much autonomy as possible 
for the nodes and cannot predict failure:of either the nodes.or the. 
‘communication network, we have no guarentee. that the node containing the. 
object will be available at any particular time. Thus, sharing by . 
making a copy may be. the only reasonable: slterpasive....ta any cage, it . 


certainly is an alternative that should be provided... 


In atau to schteve this shar ing by copying, we have defined three 
copying operat ions that we think cugie to be considered. The firet is 
the copy-one, copying just the top level of the object’ 8 structure. | 
Second, we considered the copy-full, vhich copies: the complete structure — 
of the object including any components that reside in another context. | 
Finally, we have Lobked ata novel approach to copying, the 
copy-full-local which copies a complex data hvac. to the boundary of 
the context containing that object, but no ‘further. In devising a 
mechanism for achieving these copy” ‘operations, several goals were set. . 
First and most importantly, we want to maintain any shar ing that exists 
in the original structure, because we believe this | to ‘be an important 
part of the informatica contained by ape object. “Second, we want to 
economize on mechanism by using a eideie approach ia all three 


operations. Third, since all communication between contexts is by 


rae ae 


message passing, we want to limit the amount of message passing 


“necessary; that is, copying should require as little communication back 
ard forth between the two contexts as possible. Finally, we want to 
allow for parallel processing at the sending and receiving ends of these 
copy operations. The mechanisa discussed in Chapters 3 and 4 achieves 
these goals. In order to do this, we-liave postulated two new types of 
objects, the image and the mesgage-context. Now copying simply: requires 
creating a message-context to be used to reconstruct: the sharing within 

the structure and determine which objects are to be copied as 

‘Componentes The type image is the type of object that actually can be | 
sent ina Ltlaniae Thus for each onisee enee sis meseageccontert 
determines must be copied, an. image is created ‘and sent. At the 
receiver, t the reverse is done ame nessage-context — is the moans 
of handling sharing eithia the structure and duaghe are the onsets that 
are received and that bear the information that is used to create the 


copy. 


“The procedures that have been developed in Ghapter 4 indicate that 
choy operations can be implemented in auch -@ way that the creator of a 
new extended type must do very little in order to provide these three 
operations for his type. First, he must define the operations simply as 
invocations of generic procedures: of similar names. - These procedures 
are to be provided in each context by the kemel. ’‘The other chore left 
for the programmer is to ie bene. how an a is created from an object 
of his type, by pep OmeRULGS the create image operation for his type. 


Thus the actual contents of the cote can be > type specific, yet the 
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implementer need never know about message-contexts and other details of 
the copy operations at all. Im order to receive copies, similar 
operations must be written by the programmer; receive, which invokes the 
generic receive operation, and receive-image, which transforms an image 
into an object of the type being implemented by the programmer. We have 
also shown how the mechanism can be extended to provide the three copy 
operations within a single context (in addition to copying across 
context boundaries) without requiring the implementer to distinguish 


between these calls. 


Thus, assuming our particular model of a distributed system, this 
thesis developed a solution to the problem of copying. The following 
section will assess the relative utility of the three operations and 


mechanism developed. 
5.2 Conclusion about the research 


Now that we have developed a mechanism to solve the problem 
presented in Chapter 1, we must cenaline wink has been achieved. This 
discussion will be divided into two parts. First we will consider the 
relative usefulness of the three copy operations.. Second, we will 
consider in what ways the mechanism might be simplified if we were to 


relax our goals as initially stated in Chapter 1. 


As stated earlier in the thesis, the copy-one may be considered the 
most basic of the three copy operations we have presented. In theory 
the other two operations ought to be achievable by a repeated 


application of copy-one. In practice, in order to maintain the sharing, 
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the progranmer would have to take on the function of discovering most of — 


the sharing = the message-context. The: meseage-context will only bi 
- discover sharing among Componeditis. of: a atagle object. Simulating the. - 
copy~full and copy-fallmlocal using the capyeone:.. would also involye much. 
more. message passing than we have found necessary. .It.is not clear. how 
useful. the copy-one operation ie; 4£ the objeet: to be copied is of an | 
"extended type, then copying only the top level: dpes not appear tobe 
very useful, as the actual state of the object im. etdil.only accessible. 
by passing more messages across context bouadariats: . (Of course, there . 
may well be situations in which it is dopirabie to allow the names of 


componente to Re pasead around without actually copying the eee ) 


< On the other and: if the object is a ‘base type object, there on 


difference among the various copy operations; all three should have the: 
same effect. The only attrerence in ‘this case is thather or not | 
extended types Gaing the ‘base types as | components. can have defined on 
them one or another oe the copy operations. As will be Giacusend 
further laters in order to define the ‘copy-full and poppe fulinstocal 
operations for an extended type, tt must bs clear that the relevant 
operation is defined for each component type. This will be Sonstaeted 


further in the discussions of verification and exception handling: 


‘Now, when considering the eT eee we find this to be.. 
what is most frequently considered tobe ‘the standard ‘copy operatien. 
In our model, severe complications may.arise because contexts may 
support arbitrary authorization ecnsteatats, nodes ‘may disassociate 


themselves at any time from the system,:and the communication network ag 


- 97 - 


well as the individual nodes may not be reliable. (We are not 
considering the reliability issue related to whether. or. not an 
individual message is lost or scrambled, but rather: how weeful the | 
copy~full operation is if the network has:a high.probability of. being 
unavailable at any given time.) The copy-full ise requires. the extra 
commitment in time and space to acquire capies.of all foreign components. 
in order to create ieeae Thus we are: led to conclude, that perhaps the 
copy-full is too general. 

The Coby Ev Aocal is a new “operation developed in this thesis 
that appears to strike a middle ground. “Te approaches « a solution to the 
above eriticiens of the other two. operations. Assuming some or ‘most. oF 
the components of an 2 object are ‘in the game context, most of tie” state 
of the object can be copied. | In 1 addition, if the full state of ‘the 
object is the objective, there is a savings in number of messages (copy. 
requests) and message-contexts (one raturoed for each copy request) over 
those needed if eniy copy-one operations ; are “executed. “at the same “tine: 
if the ’Gteign coaponents are unavailable for vhatever reason the | 
copy-full-local operation does. not. fail anaes the copy-fult ould. Of 
course, if instead we have the situation in. which most or all the te 
component objects are in other contexts, perhaps another pads eben 
the copy-full-local ‘may. not represent auch of a. saving. to the receiver i 
of the copy. Since the other components must also be requested in this | 
case, it will‘be necessary to access the foreiga components anyway. It 
aide means that some sharing in. the structure. may be lost, because once 


images have been created, the globally unique identities of their 
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originals are no longer attached to them. On the other side, in this 


case of widely dispersed Riupotient objects, the copy-full may be more 
expensive in terms of use of resources ‘¢nd time, sineé each of the . 
foreign components restly will be copied twice. We suspect this is an- 
unusual situation, but the only true ‘test is experience. Thus we 

| recommend that all three operations stould bi bectianke tsb cyeteee: 
similar to the one we lint aodal 1e6, -dlichougli:we-eenpact that: the 


copy-full-local will be the most ‘useful, 


The mechanism presented appears to be fairly complicated. It is 


ee worth considering vhether it could be simplitied if we relaxed some of 


our goais for the copy GParations: Our goals or constiatnte on the copy 
operations were listed in Chapter 3 and again earlier in this chapter: 
The most important one was to wainvedo 1 sharing anong components. We 
have already discussed ‘relaxing this in acquiring foreign components to 
create ne appropriate images for a copy-full. If we were to eliminate 
consideration of any sharing, we must consider vhether we could 
eliminate reper dat rotons The answer is that we could not entirely. 
It would still be meceasaty = pass to the re eenetver the names of 
“compooda is not copied in the copy-one and ‘copy-full-local eperat fons anid 
these would have to be collected somewhere. The Problem ‘is that objects 
only postete | names local to their arn en context for a number of. 
penecos discussed 40 Chapters 3 and 4. If. only names local to the 
sending context are sent in umagee the naming network would become much 
more complex. Foreign components of an » object might become inaccessible 


because one of the intermediate contexts was umavailable, mews in fact, 
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the context containing the component was available. On the other hand, 


using only the globally unique names would solve this probem, Instead 


this would cause a waste of space. Using either local names or globally 


unique names causes another problem; it allows the local names for the 
components within the sending context outeide tha hounds of. that. 
context. For security reasons, this may be undesirable, There is also 
the problem of circular lists or recursive. containment. If that were. 
not to be handled by message~contexts, there rate have to be some other 
mechanism. It = pepetnte that if Locking were used as , the oe 
syaahvontetid er peararia at could also be used to detect circularity. 
Unfortunately, as we have: mentioned, there : are | other r problens with” 
locking. Thus it is site likely that, even: ‘48 we vere ‘not. to consider 
sharing, message-contexts would provide the simplest approach | to solving 
these other problems. A relaxation of the sseond and third i goals of Sa 
Scodowietng on machaid om and Limiting ¢ cas ‘heaber of messages ‘neaded to | 
copy a component would only lead to a more. , complex mechanism because of 
the nature of the model with which we are working. The final goal of | 

alloutice images of components to be sent, received, ‘and processed 
mcparetely: if relaxed, might allow for some ‘simplification, although 
not at the sending context. A simplification would. occur “in type 
checking the structure ag it is created ether than needing to wait 
until all the components have’ been eeeated: “(this tyes checking » was not 
included in the procedures presented in chapter 4, since it is necessary 
only for reliability, an issue not addressed om this thesis. d— The 
mechanism we have Srapeated would still need images ane . 


message-contexts. At the receiver, the components could be processed in 
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the most convenient order, which is probably the order in which they 


were sent. This would simplify those functions provided by the system. 
on the other hand, “thé ‘naseage’ habdiek aight’ have to be more complex and. 
certainly would. need more buffer space, since. + woole have to collect 
and order all the appropriate pseudo-inages before the execution of the 
accive. command could start. This ‘approach would eimplity receiving a 


complete copy (copy-£ult) . in chives ‘cases in which the representations of 
the type are different in ene sending ‘and receiving contexts. It would 
7 not be of much ne2p in the case in whieh the representations are | 
different, but only 1 a@ partial ‘copy is occurring. The cradectée:. are ouch 
that it is not clear there is any benefit to be had from relaxing this 
goal. Thus we are led to conclude that the copy operations as defined 


in this thesis solve the probles presented: within the realm of the model 


postulated. 


5.3 Suggestions for further research 


Since we have used CLU as a basis:for much of our :work, it is 
‘reasonable to consider the possibility of iteluding the proposed 
operations in CLU. As CLU stands currently, it is based on a different 
‘apdas ade ours. It - assumes a user sr environment in which there is a 
single process and a single paar Sabie d (address space). However wore is 
“currently progressing in the direction of geen ipps cu ‘for a 


1 
distributed environment. Operations + similar to the pronase’ copy” 


oY et, “ bs : 
1. This work is taking place at the Laboratory for Computer Science, 
M.1.T., Cambridge, Mass. under the direction of B. ‘Liskov and D. Reed, 
however, there is as yet no published work. 
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operations of this thesis need to be considered to facilitate sending _ 


values of: abstract objects between processed in such. environments. 


This thesis has dealt with some parte of the copying problem in i 7 
distributed ayated: There are ‘related areas’ ‘that need research; 
generalisations of the: work Sresentad here are es possible. In 
acgoeaatica with this, we have a nuabar of ‘suagestions. ‘They fall into 
cheae’ categories: items 1, 2, “and 3 address additional details that have» 
to be solved wheat implementing the ‘scheae preseited in this thesis, ane 
items 4, 5, pe 6 are excuse oan the work, and item 7 is a 


generalization. 


1. This research has addressed: oaky the peablen of: sending . typed pieces, 
of information. It is clear that there are other entities that. can be _ 
in messages names, commands or ‘requests, additional control Angoreatlasy 
type nace to name a few. Further ‘reseatch. into what: Kinds. of 
messages, other than images, ies needed, This must be done in the - i 


context of a more detailed madel, of the, distributed. system. 


2. We have msatiousd vary. little abdut-veriticatiog. Much verification 
should take place at compilation time of type managers. The recefviag.” 
soucext should be able to verify that all received components are of 
appropriate type, possibly even check value ranges. tn ths édvicoument ” 
of autonomous andan. it is ieecteant ‘to ‘@o ‘geome run-time checking. ne 
Marit ioned, if a ‘copy-full or copy-full-local is defined for a type, tt 
had also better be defined for. ite components. os thie. can oe checked | at. 


compilation time for the local type ‘faanagers. tow, ‘there are » two 
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possible interpretations of a type being the same in two different 


contexts. In the first case, in addition -to the type being composed of 
the same component types, all the same operations.gre defined. In this. 
casey even for a copy-full Wiich allows foreign components, type 
che¢king can all be done at compile-time; . In: the ‘eegand. case, two types 
being considered the same means that. they heve:..the same representation. .. 
in terms of component types, and the oparatiens. of one area subset of 
the operations of the other. In other ‘words, for :‘ghoee -operations. that 
are defined on both, the operations have the. same:.effect, but not all . 
operations need be supported in aN ery context. The effect of this is 
that during a copy-full operation, run-time type Dhecking for the 

, availability of pperarione must be gone “dn t the foreign contexts. 
Although, as Peay aguely discussed, a type should be ctapowed. of the same 
‘component types at each site bebuced which copying is to occur, this | 
does not guarantee that Sopsing is defined for a specific type at each 
node on which on the type occurs. Ragaxiisas of the definition of two | 
versions of a type manager being cue same, permission to copy a 
Sarcicutes object must be checked. This can only be checked at. 
run-time. Work must also be ‘done. on guaranteeing that two type. managers. 
at different nodes really are implementing the same type if they claim 
to be, regardless of which definition .of being equivalent is used. This. 
is easy if type managers are written in .a high-level language and are . 
simply distributed to and installed (compiled) at individual nodes. . 
This is a great imposition on nodes‘and directly. threatens their 
autonomy and ability to operate wrile disassociated from the distributed 


system. It is clear that work must be dane in this area. 


- 103 - 


' 3. We have not addressed any issues of exception handling, except 


obliquely. We have pointed out several places at which exceptions might 
occur: the context boundary (insufficient authorization), unavailable 
operations (discovery that a particular operation is not defined for a. 
component type in a foreign: context), an unavailable node (the node has 
been detached from the system), an unreliable network. It may be 
difficult to distinguish some of these, but thought must be put into 


what to do when exceptions occur. 


4. It might be quite useful to be able to pass images to a context 
without requiring that the context use them to create copies, but isehee 
be able simply to assemble a collection of images for nrctus a passing 
on to a third context. In this case mia be needed in addition to 
the receive command at the receiving stce is a coauana that would imply 
just collecting images. Possible uses fe such a facility might be to 


support a file server or back up storage. 


5. This thesis has explicitly excluded the issue of moving objects. We. 
have assumed that an object resides permanently within one context. If 
it is necessary to create the appearance that an chest baw moved; this 
should be handled at a higher level by creating a copy of the object at 
the new location, deleting the original, and using a higher level name 
to point, first, to the original object and then, after the "move" to. 
the new object. There are problems associated with moving objects. One 
is the question of resolving names of objects. Since in our model the | 
name contains the name of the context, vhase..would have to be some 


policy and mechanism for how to resolve outstanding references to the 
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moved object. Further questions relate to gecuciey policies, such as if 
there is an outstanding reference to the object before it moved, should — 
that reference be updated, who has the right to: update it, when should 
this occur, and the liat goes on. This is: an ares for much more 


research. - 


6. It might be interesting to extend the aoccaack used in this thesis as 
follows. Each time a new entry is made in the psndine massage-context a 
new process is created to copy that new component... The processes all 
would use the sane message~context, 30 no sharing. would be lost. There _ 
would be a master process agsociatad with the message-context, and one... 
for each ieuscnent to be copied. In‘ ‘thie way, much sore parallelisn 
might be achieved if the hardware could support it. -I£ processes are 
not expensive, not much has been lost in overhead, while allowing for as 
much sarablal processing ae -possible.. Of course, activities involving . 
“the message-context would have to be synchronized, but that could be 
“‘managed by the process associated with the eabengercontext: This 
approach is an extension in the direction sucgued:by Atkinson, Hewitt, 


and Baker [7,8]. 


7. The approach we have taken in this thesis to copying is to translate 
every object into an image. Images ace the only objects that can be 
sent in messages. This approach can be generalized so that we have, 
instead of images, message-images, display-images, printer-images, etc. 
In other words, for each physical device there is a form in which it 
expects information. This can be used to create the apucopetate 


abstractions as we have done for the network by creating our images. 
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This should simplify the task of transferring eats to other devices. 
The programmer must specify which dee de Gene are to be defined for his 
type and write the operation ta cednetore oda of his objects into oe 
image appropriate for the device. At ‘this point the pesiewaen’ 
responsibilities should halt and the system should take over. This puts 


responsibilities where they belong. 


One of the most important considerations in looking to the future 
will be to learn more about how this kind of model would be used.(how it 
relates to the characteristics of real disteithuted applications) and ‘to. 
assess the costs (performances) .of the operationé pieapowed -in this 
thesis. It is possible that experiterice will “tadieate that different 
operations or even a different model is needed. The research presented 
in this thesis must be tested by experience cand seb secdodat of 


alternatives. 
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